Note: This is a pretty technical post, if you’re not a programmer you will probably not be interested!

A preloader gives the user something to look at while the rest of your program loads. This is one of the nice things about SWF’s, they are capable of streaming - showing part of their content before fully downloaded. The way you do this is by putting all the content to be loaded later on a later frame of the SWF timeline. This does get a little complicated, because ideally you should preload not just your data, but your code as well. Any classes you don’t need for the preloader should be placed on a later frame along with any library assets.

This is where a big bug in ActionScript 3 shows up - the “Export classes in frame” setting appears to be badly broken, as discussed on actionscript.org. As you can tell, Adobe’s error is making some professionals desperate to find a workaround. Well, thanks to others in the ActionScript community, I’ve finally discovered the workaround. Unfortunately it involves abandoning Flash in favor of Flex. But, this isn’t as bad as it may sound. While I detest the Eclipse-based Flex Builder IDE, I discovered a fantastic (and free) tool called FlashDevelop that is a superior development environment to Flex Builder or Flash, and offers easier customization while lacking just a little polish (for one thing, syntax highlighting must be edited via XML file). FlashDevelop uses the command-line SWF compiler mxmlc that comes in the new (also free) Flex 3 SDK.

Actually since Adobe has all these nebulous products floating around that all pretty much do the same thing (Flash, Flex, Air, who knows what else), it’s a little confusing what language you are using for your source files. It’s ActionScript but it’s the Flex brand of ActionScript, which is a few tweaks different from Flash ActionScript. They could just merge all these tweaks into a single language and let you choose which features you want to use, but I imagine like in many other things computer, there’s less money in making things simple. Anyway, basically in Flex-ActionScript, you can embed all your library assets via source code, rather than via an IDE. Although the way you do this is a little awkward, I find it highly preferable. And you can still use advanced layouts and components by just including them via SWC

Once you get your project converted to Flex, here is the fix: instead of monkeying around with the timeline, set your preloader as your primary build class, and use the command-line option “-frame” to put your main program on frame 2 (placing the line [Frame(extraClass="Main")] in your preloader appears to be equivalent). Thanks to this German guy Sven Busse for discovering this (unfortunately the text is German, but the source code is readable). Also thanks to Lars Gerckens for his research, and BIT-101 for this alternate solution. And of course thanks to Adobe for providing such horrendously incomplete documentation that things like this have to be discovered through much trial and error. I can’t fault them too much though, since they are at least finally strangling the abomination that was Macromedia’s ActionScript 2.

After your preloading is done, you have to start the main class - but you can’t reference it because then Flex will include it, and all the classes it uses, along with the preloader on frame 1. Here’s how you instantiate it without referencing it (’Main’ is the name of the main class):


nextFrame(); // goto Main frame
var classdef:Class = getDefinitionByName("Main") as Class;
var main:DisplayObject = new classdef(); // runs itself


Now there’s another problem - your Main class won’t have a stage object until after you call addChild(main) - but how does Preloader tell Main to initialize after, when Preloader doesn’t know what class Main is? The way I do it is by storing the stage in a global variable, then letting main add itself to the stage in the constructor. I use a class called Sys that contains static variables for build type, debug mode, stage, and a few other globals. Generally globals are a bad thing, but in certain cases like this I think they are worth it.

If you have find any caveats or improvements, let me know!

=======================

One problem still exists: when loading this in a web browser, loaderInfo.bytesLoaded seems to only reflect the first frame. We need to know the total bytes for the entire SWF to accurately show load progress. From looking at the source code to mx.preloaders.DownloadProgressBar, Adobe’s own code actually has to guess at the size of the SWF it’s loading. Weak. So no “percentage loaded” indicator is going to be accurate unless you explicitly provide it with the estimated size of your SWF.

This entry was posted on Tuesday, March 25th, 2008 at 9:49 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.