As some people know, I have a weekend gig working as an instructor for the MSF Beginner RiderCourse in Alameda, CA. Its a lot of fun, and if you have any interest, I encourage you to give it a try. If you do sign up for the course, tell Angela that I sent you!
So, back to where we were going before the digression on ApplicationDomain. One effective way of partitioning an application is to create an application shell that dynamically loads modules.
What exactly should a module look like?
ApplicationDomains are pretty much a neverending source of confusion and suffering, but they provide an interesting palette of class definition partitioning.
Anyone building an application that dynamically loads SWF files needs to learn and love the AppDom rules…
There are lots of crazy ways that one can imagine partitioning an application into multiple independently downloadable chunks. At one end of the spectrum, perhaps every single class is in a separate file, downloaded on demand by a classloader. This would be pretty inefficient, obviously – class references have significant “locality of reference”; if you need one class, odds are pretty good that there are a bunch of other classes that you will also need immediately, and it would be much more efficient to package them all together.
Determining a good packaging scheme is a pretty hard decision for the compiler to make automatically. Perhaps you would run some sort of profiler on your application during development, and monitor the class references over time. By seeing when things are referenced, in what order, and more interestingly seeing when things aren’t referenced, you could build up statistics to use for computing the optimal partitioning scheme for how many SWFs your application should be built from, and what classes should be in which. I don’t know about you, but while that sounds like a fun research problem, it doesn’t seem like its very practical, and I’d hate to have to tell my deadline-obsessed boss how long it would take to “get it working”. (Not to mention the fact that the Flash AVM+ gets really grouchy if it touches an Actionscript Bytecode (ABC) block that contains unknown type references.)
Lets look at a much more practical way of partitioning things.
In most cases, the Flex compiler constructs applications by building a two-frame Flash movie, where the first frame contains a preloader (with download progress bar graphic) and the second frame contains the bulk of the application. This allows the application to start up fairly quickly so that the user isn’t staring at a dead window during SWF download.
However, the application is still fundamentally a single monolithic SWF file. This has a few benefits, but several down sides.
As I watch Flex roll through the GMC builds, heading inexorably towards release, I realize that there’s a lot of insider knowledge that might be of interest to hardcore Flex/Flash folks – undocumented APIs, clarifications of why we made certain design decisions, details on subtle bugs that we deferred fixing and why they’re hard or risky, insight on weird player behavior, and so forth. A bunch of this knowledge only exists in my head, and since I risk lanesplitting a motorcycle across the Bay Bridge twice a day, it would probably be a good idea for me to share some of this information with the community ASAP, just in case!
