Plumbing ain’t fun, but it pays the bills…

In my last post, I whipped up a very rudimentary form UI using Flash 2004 Pro. Now I’m gonna hook up the form skeleton to some ActionScript code. A zip file containing my FLA and Actionscript file is available for download here.

I always embed as little code as possible in my FLA files. The Flash IDE design temps you to drop little nuggets of script here and there, and in the beginning it’s super-convenient. But over time, locating the code that needs to be edited or sharing your design with others becomes a real hassle. Having your code in text files makes it easier to track changes to it, and makes it easier to unit test as well.
Where we’re going with all this is the use of the “Model-View-Controller” pattern that is the bread-and-butter of application development in any sane programming environment. But before we go there we have to deal with the practical elements of how you hook up externalized ActionScript files to the flash form.
There’s three itty-bitty, nitty-gritty problems that have to be solved in order to get the code up and running. I�ll go through them in order
1)Startup: We need to start up our Actionscript objects from our FLA file. This is the one line of code that I referred to earlier.
Below is some sample code for our main controller object. Right now it doesn’t do anything except construct itself exactly once (the singleton design pattern).
class FirstController {
private static var FC:FirstController; //singleton
public static function getFirstController(){
FC=new FirstController();
return FC;
private function FirstController(){
//TODO hook up event listeners();

In the Flash IDE, I opened up the “application” screen I made last time. In the Actions window for that screen (right below the stage window) I put the following 1 line of code.
on (load) {var c:FirstController = FirstController.getFirstController();}
That’s the only line of code in my FLA file (if anyone has ideas about how to get down to zero lines please post a comment or email me or whatever.)
Now the Controller will be constructed when the application loads. Notice that
a)It’s a singleton: it can’t be constructed more than once.
b)The constructor doesn’t do anything (yet).
2)Setting up one is communication between the FLA form application and your ActionScript
This part is where the devil (ok, not the devil, the well-meaning Macromedia design team ;->) will try to tempt you into hooking your buttons directly up to function calls to your controller. Resist the siren song! With a few minutes of effort, you can keep your code in separate text files (did I mention that that’s a good idea? OK, sorry to beat a dead horse here). Flash 2004 supports an event subscription model very similar to the model used in Java.
Every action from a form widget emits an Event object to whoever is interested in hearing about it (this is the Publish-Subscribe pattern). For example, if a button is clicked on, that button will look at the list of functions that subscribe to the “click” event. To each one of these functions, it will send an Event message that gives information about what was clicked on.
Making this hookup is easy. Just add the following line to the Controller�s constructor.
The things to note are
1)_root.(application name).(FormName).(WidgetName) gets you to a given widget from anywhere inside your program.
2)We had to pass the name of the event (“click”) that we wanted to subscribe to.
3)The function that subscribes to the event is refered to by name (handleDev), but without params.
Of course, we also have to write the function that will listen to these events. According to the code listed above, it’s supposed to be a function called handleNav. Mine looks something like this:
public function handleNav(eventObj){
//handle event
3) Setting up lines of communication between the your actionscript and the FLA form
When our code has decided how the UI should change, it needs to be able to tell the UI how to change the display. In order to navigate from one form to the next, we�d only need two lines of code: one to hide the current screen, one to show the new screen.
The first line of code hides the form from which the button click originated (by getting the target of the event, i.e. the button, then getting the parent of that object, i.e. the screen, and setting visible to false).;
The second line of code shows the form that we want to navigate to
I’ve put everything in one class for now, so we’re looking at the proverbial “fat controller” (no, not your boss. Fat controller is an anti-pattern, a typical ugly trap that programmers fall into.). Obviously it would be a good idea to segregate the code that accesses the form. The designer (i.e. the person who’s the Flash layout god, but doesn’t know much ActionScript) might change the FLA form at any time. When they do that they need to know exactly where to add the corresponding code changes so that the code that accesses the form will continue to work.
Next time I’m gonna re-factor this application so that it uses the MVC design pattern, which is a generic solution to exactly this kind of problem. Sweet design pattern goodness…mmm…