You can now create modules in Flash CS4 using AS3. Â You couldn’t in CS3, but could in Flash 8 using AS2. Â Flash CS4 comes with a new feature in the Publish Settings called “External Library Path”. Â What this allows you to do is point to a set of code, and allow you to compile WITHOUT it. Â This is almost exactly the same as mxmlc’s (Flex compiler) -load-externs compiler parameter. Â We still don’t have -link-report, though, grr….
Modules refer to SWF’s that contain only the code that they need to contain, and nothing more. Â This allows large, multi-SWF Flash sites/applications to have a low overall file size, and to scale performance wise. Â If you have 30 SWF’s, and they all use the same 14k Button component, you don’t want to add 14k to each SWF. Â Instead, you want to only add it once and have all the other SWF’s share it. Â You can see how this scales nicely with not only saving massive amounts of file size, but also only loading those classes that you need at the right time. Â Here is more info on modules with regards to Flash (as opposed to Flex which embraces this concept):
- Modular ActionScript Development
- Load Random SWF’s in a Strongly Typed Way
- No exclude.xml in Flash CS3: Solution via Bridge Pattern
- Gaia Arguments, Real World Bridge Pattern, and gaia_internal
Basics of Compiling Classes
When you use the “MovieClip” class, you can’t just type MovieClip, you have to import it via:
This allows the Flash compiler to know what MovieClip you are talking about. Â MovieClip is an internal class, meaning it’s built-in into the Flash. Â Code that you write in class files (or even on the timeline) is called an external class. Â Both require a package path and import of some sort. Â This allows strong-typing to work. Â For example, if you type in:
var my_mc:MovieClip = new MovieClip();
And attempt to compile, it’ll fail. This is because the compiler knows what methods MovieClip exposes, and can do spell checking for you. Â In this case, it would complain that there is no “stoop” method on MovieClip. Â Seeing this, I’d know to change it to stop. Â This is great! Â In the past, I’d spend hours hunting down stupidÂ misspellingsÂ like this. Â ActionScript 1 didn’t do this, so a lot of bugs were from mispellings. Â Additionally, Flash needs to know what the class is so it can put it in the SWF.
When you use a Button:
var buton:Button = new Button();
button.label = “Hello”;
That Button class is compiled into the SWF. Â This is great, expected, and cool.
But what if you want to create a mult-SWF site, such as using Gaia? Â That, or you just have a very large Flash application, perhaps written for AIR, and don’t want the user to have to download & initialize the whole thing for sections they may never even go to?
In AS2, you could use exclude.xml. Â This allowed you to compile SWF’s with strong-typing, yet the actual class itself wouldn’t be compiled into the SWF. Â Naturally, the SWF didn’t work if you double-clicked it. Â BUT, if you loaded it into another SWF via loadMovie (old skool Loader), it would work if the parent SWF had the class it needed. Â You could share classes this way across SWF’s.
In Flash CS4, you can now do the same thing by creating a SWC file (a SWF inside a ZIP file). Â You can also use a folder full of classes, but SWC’s are just easier. Â You then add that SWC to the External library path in the Publish Settings for the FLA. Â This SWC’s sole purpose is to contain all the classes you DON’T want to put into the SWF.
So, if you’re creating a multi-SWF site that utilizes Flash CS3 components, you’d:
- Create a “components.fla” that has all the components you need in the library. Â You’d put those components in a MovieClip on frame 1, and export that MovieClip as “Components.swc”.
- Compile your FLA as “components.swf”.
- Any FLA that uses those components (excluding Components.fla) would put Components.swc in their External library path. Â Additionally, delete the componentShim SWC in the Library for AS3 components.
- Your main SWF first loads components.swf in the same ApplicationDomain, wait’s for Event.INIT, and then proceeds to load any other child SWF it wants.
Remember, there is no longer “_global” in AS3; you’re classes are now stored in seperate ApplicationDomains. Â Think of them as like separate _global’s that you can share or create. Â So you’re Loader call which would normally be:
components.load(new URLRequest(“components.swf”), new LoaderContext(false, ApplicationDomain.currentDomain));
You can then load everything else as normal; it’s just that 1 line of code that’s important in getting Â your component classes into the correct place to be shared (ie ApplicationDomain.currentDomain, aka “t3hÂ defaultÂ _global”).
If you were to use every Flash CS3 component, you’re SWF would be at least 80k. Â If you had to use those components in other SWF’s, even just 5, suddenly you 400k extra the user has to download. Â This doesn’t include skins and all your code. Â Using modules, you can cut down each SWF 80k.
This isn’t restricted to just the Flash AS3 components. Â This can include any class that you write as well. Â When creating large Flash sites, there are bound to be many common controls and graphics that each SWF will share. Â In the past, you’d use loadMovie, and load 1 SWF dynamically, and share it amongst others. Â Now, with modules, you can write strongly-typed code and not have to worry about sharing; you can just let the External library path optimize it for you.
It helps to do a little planning to see if any classes are shared amongstÂ multipleÂ SWF’s. Â Since Flash can’t do what mxmlc can do, and generate a list of classes used in a SWF, you have to manually guess/remember what those are based on your code. Â Additionally, even graphics & Fonts are considered classes to, so those count as candidates for being excluded.
Hopefully this’ll reduce your Flash site’s download time, or speed up your AIR app.