This article 1) describes how a Flash bug breaks the professional software-release process, and 2) entreats Adobe to fix said bug.
THE BUG: When a linked class or the document class resides in a .swc file, the Flash authoring tool can't find it, and generates an error.
At MegaPhone Labs, we separate our applications into two parts: the engine .swf (core logic) and the skin .swf (display). We create the engine .swf in Flash Builder, but we want designers to be able to easily rebrand apps, so we generate the skin .swf from a .fla file in Flash authoring. Each visual element in the app is defined as a separate MovieClip symbol in the .fla. The engine controls display by loading the skin .swf at runtime, and instantiating symbols from the .fla. The separation of skin and engine has the following benefits:
In some cases, we need to add effects code to the skin .swf. For the purposes of version control and IDE comfort, we add effects code by defining external classes, and linking them to symbols in the .fla file.
For example, for a trivia app, we might have "triviaengine.swf" (the engine), "plainskin.swf" (a skin with no code), and "flamingskin.swf" (a skin with effects code in linked classes).
Now suppose a customer, say NBC, asks us to add corporate branding to flamingskin.swf. To add the branding, the designer needs both flamingskin.fla and the linked classes. We could give the designer the linked classes in the form of raw source code (.as files). But that would be a bad idea because:
Instead of giving the designer raw source files, we want to give the designer a single precompiled .swc file, flamingskin.swc, which contains the linked classes. That way, the classes will be safely tested, version controlled, and zipped. And we want to generate flamingskin.swc via compc, not Flash authoring, as part of an automated build process.
Great idea, but due to a bug in Flash authoring (verified up to CS5), it doesn't work. When a linked class or the document class resides in a .swc file, the Flash authoring tool can't find it, and generates the error "A definition for this class could not be found in the classpath, so one will be automatically generated in the SWF file upon export."
There are some workarounds:
In our workflow, none of the preceding workarounds are worth the production effort and maintenance risks. So we are stuck giving raw source files to designers, which invalidates our testing, and adds significant risk to our software release process.
I would like to appeal to Adobe to fix this bug, and give us the tools to release products using practices befitting a professional software company. MegaPhone software is used by millions of people on television and in stadiums. We simply can't afford the risk imposed by this bug.
Thank you to Flash engineers Rebecca Sun and Jeff Kamerer for confirming this issue and providing its workarounds.