BIT-101 [2003-2017]

AS3 -load-externs


[Important Warning: the technique described here will not work in Flex Builder 2 or the original Flex 2 SDK. Although this was a documented feature, it did not work very well. And by “not very well”, I mean it did absolutely nothing. This has been fixed in Flex Builder 2.01, and I assume the Flex 2 SDK has also been updated, but you should verify that if that’s what you are using.]

Took me a bit to figure this out today, but it’s pretty cool.

You are probably familiar with this situation: You have a SWF which loads another SWF. The child SWF shares some of the classes that have already loaded in with the parent. Say the parent is 100k, and the child is 60k, but 30k of that 60 is already compiled into the parent. You need to have those classes at compile time, but you know the child is only going to exist in the parent, so there’s no need for it to carry along all that byte code. Furthermore, you might have a dozen or more child SWFs, all of which share that same 30k from the parent. It starts to add up.

In AS2 we had exclude.xml files. You had to manually figure out which classes were in the parent and which were in the child and type out an xml file that said which ones you wanted to exclude while compiling the child. I’m sure a few figured out how to automate the process somewhat, but I bet 90% of developers opened up their xml editor and type away.

AS3 actually has a few ways of tackling this situation. Actually, there are about a half dozen compiler options solely related to specifying which classes get compiled into the SWF and which will just be available for compile time checking. The one that most resembles the AS2 method is -load-externs. Here’s how it works.

First, you compile your parent SWF as usual, but you add one command line switch, either in the command line, the ant target, or in the compiler args in Flex Builder. This is -link-report=parentLinkReport.xml, of course, giving it whatever file name you want. This generates a complete report, in xml format, of all the classes that are compiled into the SWF. It also includes what classes those classes have dependencies on, what classes must be linked to prior to that class being compiled, and any classes that are externally linked to. It’s a pretty comprehensive diagnostic tool in and of itself. But the really awesome part is next.

You remember that old exclude.xml file you used in AS2? Well, there’s a new format for how that is all structured. And it just so happens that the format is the exact format that is output by the -link-report option! So, you take that link report xml that was generated when you compiled the parent SWF, and when you pass that in to the -load-externs option when you compile the child SWF, like so: -load-externs=parentLinkReport.xml.

The child is now compiled, and all the classes that are in the parent are automatically excluded from that SWF. You don’t have to analyze it and write up a list of classes. You don’t even have to think about it. In fact, you can easily set it up to be fully automated with Ant. Compile the parent and generate the report, compile the child using the report. If your parent SWF changes, adding or removing classes, the child SWF is automatically kept up to date as part of the process.

This may or may not be the ideal option for what you are doing. As I said, there are several other options, such as -externs, -external-library-path, -include-libraries, -includes, -library-path, -runtime-shared-libraries, and -source-path, that all have to do with what classes are included or not, and give you a lot of flexibility in how your apps are compiled.

« Previous Post
Next Post »