Method 3: Application SWF
The simplest way to implement an interface in your application is to have all of your components/movie clips and the interface parts in the same FLA file. You implement/skin them in, and just separate the two in your library.

Pros
Everything is consolidated; you only need to load the SWF up initially; and after that everything is already there for you (excluding external data calls). Using a combination of attachMovie and removeMovieclip/unloadMovie, you can easily make it dynamic enough because everything you need is right there. Finding a component or design asset is easy, and updating that asset is a pretty quick process. Compile one SWF, and you're done.

Depending on how you design it, you can even use Method 2 to load it in as a self-contained application. Users don't have to load any additional data, they just suffer once, and all of your assets can be loaded prior to frame 1. Not having to worry about preloaders or preloading assets in is a big help.

Cons
Try this technique on the Web and you'll get burned. First, the export before first frame option that most components come with in MX and 2004 forces that data to be downloaded first, before anything on the first frame is shown. This causes a lot of newbie Flash programmers to wonder why their users are seeing a blank white screen for seconds on end, and their preloaders don't work. Second, depending on the scope of your project, compiling as well as initialization can take a long time. First, compiling all of that code as well as compressing images, audio, and video all at one time, every time, can drag out your total compile time. If you're just making a quick code edit and wish to test it, or even a compression modification on one asset, all others must be recompressed into a new SWF – not good. Additionally, using this FLA in a source-safe type of environment (CVS) makes it really difficult because doing one minor change doesn't necessarily mean you have to check it in again, does it? For those who don't wish to have binary files in a source control system more than is necessary, this way certainly can rack up the file size, quick.

I recommend this method only for intranet/kiosk/local hard drive delivery projects, and then only for projects that don't use a lot of big media (video, sound, high-res images).

Method 4: Shared Libraries
These poor guys have gotten a lot of flak from both the designer and programmer camps – designer because they are confusing to implement and programmer because they didn't always work under every condition (like multitier). Later versions of the Flash 6 Player have remedied this, and I haven't found any problems utilizing these in Flash 7. The concept of shared libraries is that you have an asset (symbol, i.e., graphic, button, movie clip, font, etc.) in one SWF file. You export that to be available at runtime using the linkageID like you normally would, but you also check the export for runtime sharing and identify what the SWF file name will be (usually the same name as the file it's currently in, as Flash by default exports out cow.fla to be cow.swf ). You can then either drag this symbol to another FLA file to be shared, or create a new symbol in the other FLA file, and then import it in. This allows multiple SWFs to use the same symbol, but the user only has to download it once. Therefore, if your scrollbar is 10K and you use it with three other SWFs, they do not incur the 10K file size. If you update your scrollbar component, those who use the symbol are updated as well without your having to recompile the other SWFs. In later versions of the Flash 6 Player, you can also do multitier Shared Libraries (shared symbols within shared symbols).

Pros
The ability to create once and have multiple SWF files use the same symbol helps in your updates, as well as saving in file size. Instead of three SWFs using a 10K scrollbar, you now subtract that file size from them, and only incur the 10K download once to the user. Like the level approach, your compiling speed is drastically sped up in that you don't compile shared symbols symbols to a SWF… because it's already done. At author time, you still have a local copy in your FLA, though, so your FLA may still be just as big; this allows you to break the connection if the symbol needs to be unique to that SWF for some reason. Updating one SWF of components to update the look and feel or functionality of your entire application is a cool concept… and powerful. You can also use the single SWF approach in your development, but just include the asset SWFs, which will be downloaded automatically.

Cons
Shared libraries are very difficult to get comfortable with. Once you do, you get into three steps: compile the source FLAs for a change, add your components to frame 2 (or some frame not 1 in MX and before they are used code wise), and uncheck "Export Before First Frame". The multiple FLAs are another source of management…and potential debug errors since you may have forgotten to compile the source SWF, broken your linkage by accidentally editing the Shared Symbol, or had to switch to another file to edit a design change. You also have to initialize the components somehow before you use them via attachMovie or with other components. Since they're not exported before the first frame, they will not be in the final SWF file, even with a linkage ID name, unless they are used somewhere in your movie. Therefore, manually placing them on frame 2 is good. This allows your preloader to work in that all of the data is not downloaded in frame 1. You can then utilize them in frame 3 and beyond. However, for older components, or the ones that come with Flash, they use many subcomponents (subclasses), and unchecking all of these can be time-consuming. This concept of application design also spits in the face of the single frame Flash movie that programmers aspired to in 4, 5, and MX. (If you said "3 too!", you're a freak.) Although you can still emulate that "one-time download" effect, the user is still downloading multiple SWFs instead of one, and these do cache, leading to problems in testing or updates. Ever try to explain to your clients how to clear their cache, let alone what a cache is? Russian Roulette is more fun.

Application State Applied in Flash
Before we discuss utilizing one of the methodologies, let's talk about state. Application state can mean a few different things. It can refer to a design being "ready" for user input, or to a bunch of buttons grayed out because they application is "disabled," waiting for the user to choose an option on a modal dialogue, for simply "finished" or "game over man!". The nice thing about Flash's timeline and use of frames is laying this out in a timeline allows you to easily see ahead of time, create, and modify these "states." Nesting your use of graphics and movie clips allows you to have many levels of sophisticated state. Whether you actually transition between those states abruptly or gracefully really depends on skill, your time and money requirements for the project, and your style. At any rate, the simple button example in Images I and II shows how Flash handles button states when you make a button symbol.

Note: At the end of this article is information on how to get the complex mp3 radio application made using the methodologies discussed below with a complexly designed interface. And that's just for buttons. Image III is a simple timeline of a more complicated button. This is how components are sometimes set up. You'll have your component code on the top frame (which can sometimes be just an include file to your class, while in Pro, it's an external ActionScript class auto-linked to the symbol). There's also the frame labels layer that indicates the "states" of your component, which Flash can show by programmatically "playing" or "going to" these frame labels, therefore updating what is shown on those respective frames. Because this is author time, you can view and tweak your states beforehand. This helps a lot if you're required to implement a very complex animation for an "over state" and want to see how it looks beforehand (which helps show the designer how you're actually using her or his design). Scrubbing the play head back and forth (clicking on the red square, holding it, and moving it left and right along the timeline) will allow you to see your states.

Event-Based Programming vs Timeline-Based Programming
It goes without saying that the goal from the early days of Flash was to get your application into one frame. Since Flash 5, unless you were seriously pressed for time, putting anything but a "stop();" on the timeline was considered evil and hard coding. You wouldn't be flamed as people knew it would come back to bite you. Harsh justice, I know.

Viewing Image III, you would think that if one section needed to go to the next, you could just put a "gotoAnd Play(‘section')" on the frame in question, and at that point the animation would go there. Sure, that works wonders. But does your code know? Having timelines control code died in Flash 5, so picking the habit back up doesn't fly now…well, not in the long run, anyway. Having your code control the timeline from one centralized location is best since it's no longer tied to it. Initclip and his brother, endinitclip, prevent your code from running more than once, and in Pro, your code is exported on a certain frame on the main timeline and run, and you're done. Therefore, stops are just about the only thing acceptable because the timeline shouldn't control itself, but rather the code.

Informing your code of when a timeline has reached a certain point presents a problem if you can't put code on that spot, then the old adage "How do it know?" (Kenneth Payne, VB Programmer and Jack of All Trades, JRW's first mentor). Some designers and programmers new to Flash will use frames as a sequence of events. Frame 1 starts it, frame 10 does some stuff, and when ready, play frame 20, etc. This, however, has a few issues in dealing with preloading, code portability, reuse, and code centralization. What if the designer adjusts the length of the animation? What if the design itself changes and you must remove layers and animations entirely? Having code moving around the timeline, unless it's a stop, isn't safe.

"Great, Jesse, but how can we tell when we've reached that point?"

Here's my method. First, I use Method 4 in implementing the design. I decide which elements of the design can be broken into subsequent components, and then build them. Each component plays whatever animation or functionality is needed. There are common problems you run into when doing this, and I'll go over those after I describe my method.

• Source Code