Multi-SWF Applications

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.

The main benefits are simplicity of deployment (one file) and more reliable downloading (single HTTP transaction).Some disadvantages include the need to wait for entire download before starting, the fact that any trivial change will require the entire application be recompiled, inefficiencies due to the fact that not necessarily all the data downloaded was really required to support a given run of the application, and that for advanced users, it becomes difficult to create certain desireable ApplicationDomain configurations.I believe that in the future, most Flex applications will be built in a manner where functionality is split into multiple SWF files, loaded on-demand or incrementally. This will inevitably result in added complexity (partitioning decisions, multi-file deployment) and more failure modes (load errors) that increases with the number of SWF files, but I think it will be possible to use techniques to help make the advantages greatly outweigh the disadvantages.We’re not there yet. The Flex frameworks is by design a fairly monolithic blob of code. Once you touch mx.core.Application, you’re already going to pull in much of the functionality. This is why typical MXML applications start off with a fairly high initial download size, but don’t greatly increase. You’re payng a one-time cost for the framework code.Also, the compiler gives you absolutely no help. The dependency tree from a given class will be relentlessly followed and linked in. You can play some games by building Runtime Shared Libraries (RSLs) that will help with code sharing between applications, but fundamentally, you’re still needing to download all those classes (and assets) in the dependency tree of your application.So, what to do? Well, we can start experimenting with alternate architectures for applications. The good news is that the Flex compiler does in fact provide a bunch of kind of weird low-level features that can let you build some very different types of applications.In my next post, I’ll talk about one particular type of application architecture, built from a “shell” and a set of “modules”.

One Response to Multi-SWF Applications

  1. Jeremy says:

    greetings for the long-anticipated blog (and the series about dynamic loading of classes), great job 🙂