Application domains are critically important in terms of how Flex applications function, but in most cases, you don’t even know they are there. An application domain is the partition within which an application runs in Flash Player. In many cases, just one application is running in Flash Player, and in such cases, there is just one application domain. However, when you load additional .swf files into an existing application, you can create additional application domains for some or all of those additional applications.

When you load a .swf file, three possible things can occur:

Each scenario is subtly different. However, subtle differences can have a big effect, and it’s important to understand these differences so that you can understand what choices to make in each case.

All Flex and Flash applications are composed of collections of classes. An application domain holds the collections of classes for an application or applications. When just one application is running in Flash Player, the concept of an application domain is practically a formality because you are guaranteed that an .swf will never contain more than one definition for a class. However, when you load an additional .swf file, there is a possibility that it will contain a definition for a class by the same name as one that is already loaded from another .swf file. An application domain ensures that within the domain there is only one definition for each class. Therefore, it has a set of rules for determining how to choose between conflicting definitions if such a scenario presents itself.

If an application is loaded into an application domain with a parent, it essentially inherits all the class definitions from the parent application domain. The result is that the child application domain cannot have class definitions for classes that are otherwise defined in the parent application domain. For example, if you load one Flex application .swf into another Flex application .swf with the default settings, there would be two application domains but one would be a child of the other, and all duplicate Flex framework classes from the child would be disregarded in favor of the same classes from the parent application domain. This is often appropriate, and it has several possible benefits:

Just as there are cases in which this default child domain behavior is useful, sometimes it works at cross purposes with a project’s needs or requirements. For example, consider a scenario in which two applications are built using two classes with the same name but very different implementations. If one is loaded into the other, the child will not work as intended because that class will be discarded in the child, and the parent version will be used in both applications. In such a case, it is clear that there is a need to be able to completely partition the applications into separate application domains. Separate application domains ensure that the sorts of conflicts just described don’t occur. However, it is important to use these sorts of exclusive application domains only when necessary because they will increase memory usage.

The third scenario is one in which an .swf is loaded into the same application domain as the loading/requesting application. This is the behavior utilized by runtime shared libraries. It is also useful when you want to load libraries of fonts and other assets at runtime for use in the requesting application.

You create each scenario (exclusive application domains, parent/child application domains, and same application domains) by specifying a flash.system.LoaderContext with the appropriate setting when calling the load() method of a flash.display.Loader or a flash.net.URLLoader object. The LoaderContext class defines an applicationDomain property. Setting the value of this property determines the application domain for the loaded content. The applicationDomain property is of type flash.system.ApplicationDomain. The ApplicationDomain class has a static property called currentDomain that is a reference to the application domain of the requesting code.

It's possible to use a LoaderContext and an ApplicationDomain object (in conjunction with the currentDomain property) to achieve the necessary behavior for each of the aforementioned scenarios. For instance, you can achieve the default behavior (the content is loaded into a child domain) by passing no second parameter to the load() method. You can achieve the same behavior when passing a LoaderContext object with the applicationDomain set to a new ApplicationDomain object that uses ApplicationDomain.currentDomain as the parent application domain. You do this by passing ApplicationDomain.currentDomain to the constructor of the constructor, as shown here:

var context:LoaderContext = new LoaderContext();
context.applicationDomain = new ApplicationDomain(ApplicationDomain.currentDomain);
var request:URLRequest = new URLRequest("RuntimeLoadingExample.swf");
var loader:Loader = new Loader();
loader.load(request, context);

You can achieve an exclusive, separate application domain for loaded content by constructing an ApplicationDomain object with no parameter passed to the constructor:

var context:LoaderContext = new LoaderContext();
context.applicationDomain = new ApplicationDomain();
var request:URLRequest = new URLRequest("RuntimeLoadingExample.swf");
var loader:Loader = new Loader();
loader.load(request, context);

If you want to load the content into the same application domain, you can simply use ApplicationDomain.currentDomain:

var context:LoaderContext = new LoaderContext();
context.applicationDomain = ApplicationDomain.currentDomain;
var request:URLRequest = new URLRequest("RuntimeLoadingExample.swf");
var loader:Loader = new Loader();
loader.load(request, context);