The Process Clip Revisited
I first have constants – variables with capital names for which I make an agreement to never change their value. They're named after the frame label (plus a "_DONE"), and their value is equal when that frame label's animation is done. That way, if the timeline gets moved around, I just change the constants variables' values.

Second, I determine which state happens when. Sometimes, you get lucky and only have to code a forced state change, like a Flash button. It goes wherever you are. Sometimes, though, in assembly-type interfaces, the designer has provided a transition from point B to point C, from point C to A, etc. All the permutations I'm assuming are done for me (although I end up doing them because I have little contact with my designers on how the project is put together sometimes, or the way they created it behooves me to re-create it myself. Production Artist, anyone?). With all of these scenarios set up, I code a function that gives me a frame label to go to based on where I am at currently, passing in a frame label that says where I'd like to go. So, if I want to shut down, and my app is currently open, it'll need to play the "close menu" animation. It's generally one big arse nested switch statement (or if/else if you are so inclined). You pass in the frame label your currently at, and it determines where to go (see Code 1).

This allows you to get to any point from any point. This requires you and the designer to hash out all possible scenarios of each component/module, and then for the designer to create the animations for those transitions/scenarios. The programmer may have to modify some of the interface elements; the ones that need code associated with them by giving a movie clip an instance name on a certain frame.

Finally, we get to the engine to instantiate the change in state, as well as knowing knowing when state has been truly reached. This can be coded in two ways: lazy evaluation and strict evaluation. Since I'm a programmer, I'll show the lazy way. Strict is merely stating that you cannot change state while transitioning to another state (animating the component/movie clip/showing the animation), while lazy just plays what it needs to, knowing the stops will take care of stopping the animation at its proper time. Designers and sales people obviously love strict bcause it appears smart, and strict almost always involves transitions. What they don't realize is if you're trying to change a combo box to "open" so you can populate data that just came back from a Remoting call, but you're using strict and your code responds with a "no, sorry, not yet," then the combo box doesn't get its data. You're not allowed to code the combo box to get the data when it's ready; that's cheating. The way around it is using the constants in step one: "He's there, send the data to those who need it."You can either hard code these data broadcasts in your getFrameLabel function, or make a generic function to call whenever state is finished (a button is finally on the stage, ready to have it's label set via a Remoting call's record set result and its click handler pointed to wherever). Either way, you use an onEnterFrame function on a movie clip. The enterFrame event fires every frame iteration, ensuring that every time the play head moves, you get an event. Even though most programmers like intervals, the timing is not so exact that you'll get it fired on every frame, while onEnterFrame will. Code 2 shows the functions that go in your component.

Now, before you go asking how to animate components, you simply:

• Put your components in a movie clip
• Give it an instance name
• Place the movie clip on the timeline where it is to be animated
• Give it an instance name
• Animate it

this.movingCheckBox_mc.my_ch.set
Value(true);

Now, notice the inefficiency here: either you code one function to populate all of your components on each state change with data, even if they don't exist, or hard code the data setting to the frame label. I recommend the latter; even though it's more work and you're duplicating function calls, the data that needs to be set will get set when you need it to. This is a bigger deal if the call is asynchronous, like XML or Remoting.

To pull it all together, each component uses the above process and is put in its own FLA file, with its component name as the FLA (in Pro, the component class as its class name.as). You then link the symbol for runtime sharing.

Pull them all together (drag all their symbols into the main movie's library), put your preloader on frame 1, your shared symbols on frame 2, and your app on frame 3.

Conclusion
Ultimately, the process of implementing complex interfaces and animations in Flash goes smoothly if the details on how it works (transitions from state to state, or not at all) are ironed out, up front, with face-time collaboration. Having the designer and Flash programmer work out how it can be assembled, confirming all states for each component, and having the designer create and animate those states will lead to a smooth process. It's by no means easy, but the ability to sell this application as compared to other, non-Rich Internet Applications, as well as its positive impact on the user, is profound. Besides, true Flash programmers revel in this because they know what they are creating is high-end and cool – the designer can see her or his creation work, and the user ends up reaping the benefits of a labor of love.

For an example using the code here, please see this article's accompanying Flash file, Neos Radio, at www.syscon.com/mx/sourcec.cfm.

Also, for additional discussion on application state applied to Flash, please see www.darronschall.com/weblog/ archives/000014.cfm as well as www.stalker.com/CommuniGatePro/Web App.html under "Stateless and Sessionbased Processing".

Design provided by David Allbritton (www.daveallbritton.com), hacked apart by me.

• Source Code