Agile Enterprise Application Development with Flex

Sibling Domains and Multiversioning

By now, it should be clear that applications, modules, and libraries (albeit bootstrapped as applications) are simply different forms of packaging .swf files. Libraries assume the tightest coupling with the loading code, and that’s why they get preloaded (by the application’s code generated by the Flex compiler). Modules get loaded and unloaded on demand, because they are needed only conditionally and only temporarily. Applications are similar to modules, in that they get loaded and unloaded on demand. The important advantage of applications over modules (as units of modularization) is that applications are self-sufficient, which allows you to mix multiple application .swfs compiled against different versions of the Flex framework (Flex 3.1, Flex 3.2, Flex 4.0, and so on).

Let’s elaborate. As you already know, libraries get loaded into the same domain as the application: ApplicationDomain.currentDomain. Accordingly, to avoid conflicts, a library has to be compiled against the same version of the Flex framework as the enclosing application. With modules, you get to choose between the same domain or a child domain (new ApplicationDomain(ApplicationDomain.currentDomain)), but even in the latter case, the class search starts with the parent domain. Again, to avoid conflicts, modules have to be compiled against the same version of the Flex framework as the consuming application. When it comes to applications, you still may use same-domain or child-domain ...