Coordinating multiple developers

Multideveloper projects present unique challenges. Because the Flash source FLA file format is binary, it is difficult for multiple developers to work on the same source file. The management of large Flash projects is further complicated because both designers and engineers will have reason to modify FLA files during development.

For these reasons, large Flash projects require more planning, coordination, and discipline than large projects built with text-based source files, such as HTML, JavaScript, or Java. We adhere to a few rules of thumb to help us effectively manage these projects.

Keep engineers out of FLAs

With few exceptions, engineers who write ActionScript do not make changes to FLA files. Designers create the visual elements in FLA files, which the code written by engineers then manipulates. Two techniques help us obey this rule:

• Manual class registration: We bypass Flash’s ability to associate an ActionScript class with a MovieClip symbol in the library by specifying the class name in the Property inspector. Instead, we use old-fashioned calls to the Object.registerClass function to make that association. The benefit of this approach is that it moves the creation and maintenance of the association out of the FLA file and into ActionScript files.
• Autogenerated MovieClip symbols: We exploit the implicit library symbol that Flash automatically creates for every ActionScript class. Every class generates a MovieClip symbol named for the class, with a prefix of “__Packages”. A class with a full name of six.feet.Under will cause Flash to generate an empty MovieClip library symbol named “__Packages.six.feet.Under”. MovieClip subclasses without vector graphics don’t need to exist in the library of the FLA. Our code can call drawing API functions or perform any other MovieClip operations without explicitly being defined in the library of the FLA.

Create multiple FLAs

We create multiple FLA files to implement the user interfaces of large projects. There is typically one “shell” FLA that contains the main user interface and any commonly used pop-up windows, assets, and dialog boxes. The other modules of the application are defined in separate FLA files. These FLA files are compiled into SWFs, which are dynamically loaded into the shell SWF at runtime using some permutation of the loadMovie function.

An extension of this approach is the generation of multiple SWFs from a single FLA. This strategy is particularly useful if multiple, similar visual elements are used in distinct circumstances. We define separate MovieClip symbols in the library for each visual element, which can share visual subcomponents. We then generate SWFs for each of them by right-clicking the symbol in the library and choosing Export Flash Movie from the pop-up menu. One complication of this technique is keeping track of all the SWFs you export. To address this issue, we name the SWFs the same as the MovieClips that spawn them.

Maintaining a consistent look and feel across the application is one challenge in aggregating many separate SWFs into a single coherent application. We improve the visual consistency of the user interface by using the same global skinning mechanism across all the separate FLAs. When we use the Adobe Flash MX2 component set, we use style sheets to accomplish this.