I learned to program in Flash
— WARNING —
This post may come across a little harsh, make me sound angry, produce some new enemies or even turn you off to the idea of ever doing work with me, but please remember to take it with a grain of salt as I am just one man with a small gripe to get off his chest.
— WARNING —
I don’t typically like to write “rant” posts, but there’s something that has really started to grate at my developer nerves lately and I need to get it out there. When I stepped into Flash back in ’98/’99, I had no idea that it would end up being the main tool at the base of my career. You see, I graduated from The Art Institute of Dallas with a degree in 3D Animation and wanted to end up working for someone like Pixar or any other similar company. Well, as we all know, most people don’t come directly out of college and go into that dream job and I was no exception. I got a job that introduced me to Flash and I started learning it… first with simple tweens and animations and then on to this thing called ActionScript. This brings me to my point: I learned to program in ActionScript as opposed to some other “real” programming language. So what should bother me about that? There’s LOTS of old school Flash guys and gals out there that learned the same way, right? And together we helped Macromedia (and Adobe) grow the Flash Platform into what it is today, right?
A lot of developers that I’ve met who come from a background with “real” programming languages (C#, Java, etc.) and who have computer science degrees have long looked down upon us lowly ActionScript developers because ActionScript was considered a joke and not a real language. However, we kept our skin thick and persevered despite their condescending attitudes and attempts at programmer insults. But now things have changed. Now we have ActionScript 3. Now we have Flex 2, 3 and soon 4. And now we have those same developers migrating over. WHICH IS GREAT except for one thing… many of them still want to tell us how we’re “doing it all wrong” and then, in the same breath, ask us how to complete a given task in ActionScript. Here’s an idea: Let’s all learn from each other and let’s keep a mutual respect for each others’ training, knowledge and backgrounds.
Something else that’s more amusing than frustrating to me is that I still hear some of them complain about Flash and/or ActionScript in such ways as to make me want to ask them why they are working with it if they hate it so much. “Jason, why does Flash work this way? It’s really wrong and really messed up…. Jason, I can’t believe ActionScript doesn’t have a ______ method! Why doesn’t it have a ______ method like the language in which I learned to program? This is all wrong and really messed up.” To those I answer: Call Adobe or check out bugs.adobe.com.
Anyway, before I finish up on this post, I feel like I should add that I DO realize that I’m generalizing a bit here. I know that not all traditional developers are this way and I also know that the teams at Adobe who actually produce these products most likely come from these backgrounds. However, I’ve seen and heard so much of it lately that I just wanted to bring it up. And now I’ll move on and get back to thickening my skin again.
I learned to program in Flash and
- I don’t have a computer science degree
- I write BOTH procedural AND object oriented code
- I use the timeline when needed (animation and/or code)
- Design patterns are not my #1 priority
Thanks for reading.
The comments are open.
TexFlex – Dallas Flex Camp (Reminder)
Just a quick reminder that TexFlex is coming up this weekend and tomorrow (Oct. 15) is the last day to register.
What:
TexFlex – Dallas Flex Camp
Miller & Associates and Adobe invite you to join us at Flex Camp, a one day gathering with food, drinks, and coding covering everything you need to know about Flex 3 and Adobe AIR.
When:
October 17 from 9:00 AM – 6:00 PM
Where:
The Marriott at Legacy Town Center in Plano (MAP)
Agenda:
Doors open for Flex Camp at 9:00 AM
9:00 AM – 10:00- Registration, Food, & Drinks
10:00 AM – 10:30- Keynote / Introduction: Bob Tierney *Provided by Adobe
10:30 AM – 11:00- Welcome: Mark Miller
11:15 AM – 11:45- Breakout Sessions
BUSINESS
11:45 AM – 12:30- Camp Session 1: Michael Smith- Rich Internet Enterprise Application
12:30 PM – 2:00- Lunch Break
2:00 PM – 2:45- Camp Session 2: Bob Tierney- Flex and LiveCycle Data Services
2:45 PM – 3:00- Break
3:00 PM – 3:45- Camp Session 3: Jonathan Campos- The Hidden ROI of a Flex RIA
3:45 PM – 4:00- Break
4:00 PM – 4:45- Camp Session 4: Carter Bradford- Comparing Flex with other RIA Technologies
4:45 PM – 5:00- Combine Groups
DEVELOPERS
11:45 AM – 12:30- Camp Session 1: Mark Piller- Cross Platform Client/Server Flex Development
12:30 PM – 2:00- Lunch Break
2:00 PM – 2:45- Camp Session 2: Jonathan Campos- Flex Libraries: Making Reusable Code Reusable
2:45 PM – 3:00- Break
3:00 PM – 3:45- Camp Session 3: Michael Smith- Building Components with Adobe Flex
3:45 PM – 4:00- Break
4:00 PM – 4:45- Camp Session 4: Andrew Longley- Making Flex Events Work for You
4:45 PM – 5:00- Combine Groups
5:00 PM – 6:00- Closing Q&A (All presenters as a panel)
Presenters
*Bob Tierney has been with Adobe for 4 1/2 years, having started with Macromedia during the Flex 1.0 days. He is currently a Senior Product Specialist for Flex / LiveCycle Data Services in the North American Sales organization. Prior to Adobe, he was the Evangelist for SilverStream Software, one of the very first Java Application Server vendors. Before SilverStream, he was the PowerBuilder Technology Evangelist for Powersoft Inc, a very successful GUI based client server development tool. That accounts for the second half of his career. In his previous career, Bob was an Electical Engineer specializing in the area Digital Simulation and Fault Analysis for VLSI Devices – which explains the jump into IT software development.
Mark Piller is the founder and Chief Architect of Midnight Coders, an innovative and forward-thinking company specializing in the RIA integration technologies. Mark has over 15 years of software development experience. For the past 5 years he has been specializing in building software infrastructure products designed to integrate Flex, Flash and AJAX applications with a variety of backend systems including .NET, Java, PHP and Ruby on Rails. Mark is very passionate about ease-of-use of software and prides himself in creating technologies that clearly demonstrate that quality.
Jonathan Campos, user group manager of D-Flex.org, is an enthusiastic Flex user that has worked with the Adobe’s Flex technology for a variety of small to mid-sized companies. Having worked on an array of different Flex projects Jonathan has had to learn Flex “in the field” as he created a diverse portfolio of Flex based programs for both the web and AIR applications.
Jonathan’s experience lies in application planning and development, programming, and the integration of Flex with multiple different server side technologies.
Carter Bradford has been working as an IT Consultant for the past 10 years with an emphasis on IT strategy and large-scale systems integration. Much of this time was spent working on international assignments including projects in Finland, Brazil, and Japan. Prior to this, he was a research engineer working on various projects for the Department of Defense. Carter has been working with Flex since the 1.0 days and has a keen interest in the web and browser as a platform for enterprise applications.
Andrew Longley has been with Miller & Associates for less than a year but has been using Adobe Flex for almost four years. Longley is currently supporting one of Miller & Associates oldest clients building custom Flex and Air applications. Prior to that, he supported a Flex UI for a company in the telemetry services business, initially converting the application from Flex version 1.5 to Flex version 2.0, and then building upon the large collection of drag-and-drop widgets used to represent readings on remote devices. Longley initially used Flex in 2004 and 2005 to build a threat response system while on contract with Lockheed Martin. Each of these applications make heavy use of the Flex event framework.
Sponsors:
Miller & Associates
Adobe
Sometimes it’s the small things (like shortcuts)
Over the last few days I've learned about two small things in Flex that I really like. Bookmarks and the Ctrl+Space shortcut. It's because of these two items that I've decided to make a new category named "Shortcuts" in which I will make quick, short posts about... well, shortcuts. Some of these will be items that I may have seen before but never paid much attention to and some of them will be things that I never knew existed. At any rate it will be a category that can be used to find quick little tips that may help increase productivity by speeding things up (even if only by 1 second in each instance). So to start off this category I'll talk about the two that I've just learned.
Product: Flex Builder 3
Shortcut: Bookmarks
I picked this one up at Marco Casario's blog and I was immediately asking myself why I had ignored this in the past. These bookmarks are basically what you would expect them to be by their name and they are awesome. Since reading Marco's post I've been adding/using bookmarks like crazy so I can jump right to any function, variable, etc in any file at any time.
Product: Flex Builder 3
Shortcut: Ctrl+Space
The Ctrl+Space shortcut is one I just learned about a few minutes ago while working through the introduction to Cairngorm (yes, I've decided I need to pick up Cairngorm). The Ctrl+Space shortcut is great especially in a situation where you need to move a variable declaration from one class to another (or from a mxml file to a class).
So here's the situation: You have cut the variable declaration from the AS in your mxml file and pasted it in your class. Since you pasted it instead of typing it in directly, Flex doesn't automatically include the import line. By placing your cursor at the end of the name of the class and pressing Ctrl+Space, Flex will add the import line for you. So in this instance:
-
private var myVar:URLStream = new URLStream();
You would place your cursor after the "m" in "new URLStream" and press Ctrl+Space and Flex would respond my placing the import line at the top of your class:
-
import flash.net.URLStream;
Making Flash and Flex talk (Part 2)
As promised in my previous post, here's part 2 of Making Flash and Flex talk. This post is going to be a bit shorter than part 1 since a lot of the code and information is the same. You'll see in the example that the user experience is the same in both this post and part 1. However, by using listeners and a custom event in this example, we lessen the chance for error that could be caused by calling a function directly by name in a child (parent) file.
This example involves a total of 4 files: FF_Talk.mxml, FFTalkEvent.as, ffTalkSwf.swf and, of course ffTalkSwf.fla.
You can view the source code either here or by right-clicking on the example and clicking "View Source". You can also grab the zip containing these files via the download link at the end of this post.
THE CODE:
Let's take a look at the source and break it down just a little.
FLEX SIDE:
As in part 1, I start by declaring the variables flashSaid and mySwfMc. This time however, I also import a new class file named FFTalkEvent which will serve as the means of communication between Flex and Flash in this case. More about FFTalkEvent below.
-
import com.fincanon.events.FFTalkEvent;
-
-
[Bindable]
-
private var flashSaid:String = "";
-
private var mySwfMc:MovieClip;
Also just like in part 1, the next thing in the mxml file is the setSwfMc function. This function still casts the content of the SWFLoader as a MovieClip but now it adds an event listener to both the loaded swf and its Flex parent (instead of sending a reference of the Flex parent into the swf).
-
private function setSwfMc():void{
-
mySwfMc = mySWFLoader.content as MovieClip;
-
mySwfMc.addEventListener(FFTalkEvent.TALK_TO_FLEX,listenToFlash);
-
this.addEventListener(FFTalkEvent.TALK_TO_FLASH,mySwfMc.listenToFlex);
-
}
Next are the functions listenToFlash and talkToFlash (you'll also recognize these from part 1). The big difference this time is that we're either listening for or dispatching a new FFTalkEvent instead of making the more "dangerous" move of calling a function directly by name. By NOT calling a function directly by name, some of the possibility for error is removed. In part 1, I was calling function in the child swf... but what if that function wasn't there? The results of that call could end up bringing the user's experience to a grinding halt.
-
private function listenToFlash(e:FFTalkEvent):void{
-
flashSaid = e.said;
-
}
-
-
private function talkToFlash(stringToPass:String):void{
-
dispatchEvent(new FFTalkEvent(FFTalkEvent.TALK_TO_FLASH,false,false,stringToPass))
-
}
As you can see in the source, the rest of the mxml file is simply the text fields, labels, buttons, SWFLoader, etc.
FLASH SIDE:
Again, as in part 1, the code in the child swf is not that far off from the code in the parent mxml. Also, the main difference between this version and the version in Part 1 is the fact that we're importing FFTalkEvent and we're listening for or dispatching new instances of FFTalkEvent.
-
import com.fincanon.events.FFTalkEvent;
-
-
function talkToFlex(me:MouseEvent):void{
-
dispatchEvent(new FFTalkEvent(FFTalkEvent.TALK_TO_FLEX, false, false, flashInputTxt.text));
-
}
-
-
function listenToFlex(e:FFTalkEvent):void{
-
flexSaidTxt.text = e.said;
-
}
-
-
talkToFlexBtn.addEventListener(MouseEvent.CLICK,talkToFlex);
FFTalkEvent:
FFTalkEvent in its current state is a simple, straight forward, bare-bones class that extends Event. It contains a couple of constants (TALK_TO_FLEX and TALK_TO_FLASH) and a String var named said. If you notice above, we call the said variable to get the value that was passed from Flex to Flash (or vice-versa).
-
package com.fincanon.events{
-
import flash.events.Event;
-
-
public class FFTalkEvent extends Event{
-
public static const TALK_TO_FLEX:String = "TalkToFlex";
-
public static const TALK_TO_FLASH:String = "TalkToFlash";
-
public var said:String;
-
-
public function FFTalkEvent(type:String, bubbles:Boolean=false, cancelable:Boolean=false, sentString:String="") {
-
this.said = sentString;
-
super(type, bubbles, cancelable);
-
}
-
}
-
}
THE EXAMPLE:
WHERE TO GO FROM HERE:
Like I said, FFTalkEvent in its current state is a simple, straight forward, bare-bones class. While this example is simply passing a string, you can see where it could very easily be built upon to handle much more complex tasks and I'll most likely take the time to do that in down time between projects. Whether or not I post future versions may depend on how much feedback/interest I see with this version.
DOWNLOAD THE ZIP:
Source files here.
Making Flash and Flex talk (Part 1)
I recently ran into some issues making Flex talk to a loaded swf while also allowing that loaded swf to talk to its Flex parent. I had done it once before on a prior project but since it was a one-time deal, I had forgotten exactly what I did to accomplish the task. I knew it had to do with casting the SWFLoader.content as a MovieClip, but I still needed to go digging back to the old project to make sure I had all of the correct steps. That was when problem #2 showed up... I couldn't remember which project I did this in. So, as the next logical step, me and a friend started doing some research online and found less than satisfactory results/answers to our questions.This lead me to feeling the need to write this post not only for my own future reference but also in hopes that it may show up in someone else's search results and help them in the future.
This example involves a total of 3 files: FF_Talk_Simple.mxml, ffTalkSimpleSwf.swf and, of course ffTalkSimpleSwf.fla.
You can view the source code either here or by right-clicking on the example and clicking "View Source". You can also grab the zip containing these files via the download link at the end of this post.
THE CODE:
Let's take a look at the source and break it down just a little.
FLEX SIDE:
In the mxml file, I start by declaring a couple of variables (flashSaid and mySwfMc).
flashSaid will be used to populate a dynamic text field so you can see that your string has actually made it from Flash to Flex and mySwfMc will be used as a reference to your loaded swf child.
-
[Bindable]
-
private var flashSaid:String = "";
-
private var mySwfMc:MovieClip;
Next, is a function named setSwfMc. This function is called from the SWFLoader when your child swf has finished loading. Once called, setSwfMc does two things. First, it casts the content of the SWFLoader as a MovieClip (this is required in order to access everything inside the child swf). Next, it passes a reference to the Flex parent into the child swf (this will be covered in the Flash code below).
-
private function setSwfMc():void{
-
mySwfMc = mySWFLoader.content as MovieClip;
-
mySwfMc.myFlexParent = this;
-
}
The other two functions in the mxml file handle the communication on this end of the conversation. They are named listenToFlash and talkToFlash and you can probably guess what they do pretty quickly. listenToFlash will be called from the child swf and it is expecting a to recieve a string. Once called, it takes that string and assigns it as the value of the flashSaid variable mentioned earlier. Since that variable is [Bindable], the text field is updated and you know it worked. The other function here, talkToFlash, is very similar but it is sending instead of receiving. Within talkToFlash, we are calling a function named listenToFlex that resides in the child swf. Much like the listenToFlash functon, listenToFlex is expecting a string to be passed.
-
public function listenToFlash(stringToShow:String):void{
-
flashSaid = stringToShow;
-
}
-
-
private function talkToFlash(stringToPass:String):void{
-
mySwfMc.listenToFlex(stringToPass);
-
}
FLASH SIDE:
The code in the child swf is not that far off from the code in the parent mxml.
If you recall from above, we passed a reference to the Flex parent into the swf and assigned it as the value of a variable named myFlexParent. So it stands to reason that we need to declare such a variable and that's the first thing that happens in the swf. Next, we do just as we did in the mxml file and set up the conversation functions (talkToFlex and listenToFlex). Since these do pretty much the same thing as their counterparts in the mxml, I'll save you the trouble of reading it twice (and me the trouble of typing it twice). The last thing you see in the code below is just the listener for the button to talk to flex.
-
var myFlexParent:Object;
-
-
function talkToFlex(me:MouseEvent):void{
-
myFlexParent.listenToFlash(flashInputTxt.text);
-
}
-
-
function listenToFlex(stringToShow:String):void{
-
flexSaidTxt.text = stringToShow;
-
}
-
-
talkToFlexBtn.addEventListener(MouseEvent.CLICK,talkToFlex);
THE EXAMPLE:
UP NEXT:
Part 2 of this topic will be very similar to this post except that I will be implementing listeners and a custom event to communicate between Flex and its loaded swf child. I'll try to have that up today or tomorrow.
DOWNLOAD THE ZIP:
Source files here.




