Flash: Classes and Packages

At Barefoot we have many different kinds of developers. Some come from a Java background. Some have been using Flash since Macromedia purchased it and released it as Flash Version 3. In addition, we work with developers from other agencies or from our clients and that requires project portability.

In this case, portability means the ability to package up a project with all of its pieces and deliver it to someone else in a way that they can begin working on the project without problems caused by missing dependencies.

We also use Subversion as a version control system. One way we use Subversion is to deliver project packages. Because of the way Subversion works, we have to be concious of file system restraints. The majority of the time, this means all of our project files need to live under a main parent directory.

This brings us to the organization of files that make up our projects, in this case Flash projects.

At Barefoot, we borrow a practice from the Java paradigm called Classes and Packages. For in-depth information about using Classes and Packages in Flash, check out Collin Moock's O'Reilly book–Essential Actionscript 2.0 - http://moock.org/eas2/.

In simple terms, Classes are external Actionscript files. Classes are how logic for your Flash application is separated and stored.

Packages are simply a set or group of interrelated classes in a file structure.

So for example, say Barefoot has created a custom Video Player to play FLV files.

We would have a Flash directory to hold all of our files related to the project. This includes any Classes. Default Macromedia Classes can stay in their default directory since we assume anyone else working on this project has Flash, including those core Classes. We also don't add Classes to the default Macromedia directory, all of our custom Classes stay with the project–including our FLA file.

Inside our Flash directory we'll store our FLA(s). We'll also want to store our Packages, remembering that they are just groups of our Classes that are interrelated.

This is where we borrow from Java and other mature language paradigms. We don't want our Packages, and the Classes inside them, to interfere with code from other developers. So, we store them in unique namespaces. The standard is to start this namespace with our company's domain name.

Inside the Flash directory with our FLA is a "Classes" directory. This becomes the root directory of the classpath, or the place where we tell Flash to look for any classes it needs to find. In "Classes", we add a "com" directory. And inside that is a "thinkbarefoot" subdirectory. Get it, thinkbarefoot.com? Now going back to the example, we'll create a "videoplayer" subdirectory inside "thinkbarefoot." Again, this is all covered in Moock's book.

\flash
 |
 +--\Classes
 |     |
 |     ---\com
 |          |
 |          ---\thinkbarefoot
 |                |
 |                ---\videoplayer
 |                      |
 |                      +--Player.as
 |                      +--Loader.as
 |
 +---video_player.fla

Inside the "videoplayer" directory will be all of our Classes (*.as), along with maybe some other subdirectories if we break things out further.

Organizing our files like this has two advantages. First, a check-in to Subversion only has to contain one parent directory. Then, if we deliver the project to someone else, all we have to do is zip the Flash directory and they'll have everything they need. That portability is essential when you are working with multiple developers or sending your code to another company.

Without this level of file organization, you may deliver an FLA and some of your logic, but forget one key Class that prevents a future developer from compiling a quick text fix. Adobe has made Actionscript 2.0+ very friendly for use with Classes and Packages. Give them a try, you'll be happy you did.

Mike Krisher, Senior Developer, Barefoot
Doug Smith, Senior Developer, Barefoot