About application domains

An application domain is a container for class definitions. Applications have a single, top-level application domain called the system domain. Application domains are then defined as child nodes of the system domain. When you load a sub-application into another, main application, you can load it into one of three application domains: sibling, child, and current. When you load a sub-application into a sibling application domain, the sub-application’s application domain has the same parent as the main application’s application domain. In addition, it is a peer of all other sibling applications.

When you load a sub-application into a child application domain, the sub-application’s application domain is a child of the main application’s application domain. When you load a sub-application into a current application domain, the sub-application is loaded into the same application domain as the main application. Each of these locations defines where the sub-application can get its class definitions from.

The default behavior of the SWFLoader and Loader controls is to load a sub-application into a child application domain. If the sub-application and the main application are compiled with different versions of the Flex framework, runtime errors can result. These errors occur because the applications are sometimes compiled against different definitions of the same classes.

You can specify that the main application loads a multi-versioned sub-application. It does this by loading the sub-application into a sibling application domain. This means that the sub-application defines its own class definitions and does not get them from its parent. It is possible for two applications to work together, even if they are compiled with different versions of the Flex framework.
Note: In a multi-versioned application, the sub-applications must be compiled with the same or older version of the compiler that the main application was compiled with.

You specify the application domain of a sub-application by setting the value of the loadForCompatibility property on the SWFLoader. If you set the value of this property to true, then the sub-application is loaded into a sibling application domain. If you set the value of this property to false, then the sub-application is loaded into a child application domain. The default value of this property is false, so by default, sub-applications are not multi-versioned.

You can also specify the application domain on the LoaderContext object. You do this if you specify the value of the loaderContext property when using the SWFLoader control. For more information, see Specifying a LoaderContext.

The system domain

Classes defined by Flash Player are in the system domain. The system domain parents all other application domains. The main application’s application domain is a child of the system domain. If you load sub-applications into sibling application domains, then they are also children of the system domain. Classes defined in the system domain are never redefined in sub-applications or main applications. Those applications all share the common definitions of Flash Player. These definitions include classes such as DisplayObject, Event, and Sprite. The definitions of these shared classes are contained in the playerglobal.swc file.

Sibling application domains

The application domain that a sub-application is in determines where the sub-application gets its class definitions from. If the main application loads a sub-application into a sibling application domain, the sub-application defines its own non-player class definitions. This is the configuration for multi-versioned applications. Applications that are loaded into a sibling application domain can load other applications into a sibling application domain.

sub-applications that are in sibling application domains of the main application can communicate with the main application. Sub-applications can call methods and access properties on the applications, as long as they meet these criteria:

  • Only strong types that are defined in Flash Player are used.

  • The sub-applications are not in different security domains.

The ability for a sub-application in a sibling application domain to communicate with the main application is not as seamless as when the sub-application is in a child application domain. For example, if the sub-application launches a pop-up control, it passes an event to the main application that actually launches the control. This event passing limits their communication somewhat, but does provide some measure of interoperability. For more information about developing this type of application, see Developing multi-versioned applications.

Applications that are in separate security domains are automatically in separate, sibling application domains. As a result, if you load an untrusted sub-application into a main application, that sub-application has its own class definitions.

Child application domains

If a main application loads a sub-application into a child application domain of its application domain, the sub-application gets its class definitions from the main application. This behavior is the default for application loading. It can result in runtime errors if the applications are compiled with different versions of the Flex framework. As the SWF file sets up its classes, classes that are already defined are not added to the application domain. First in wins, which means that the first class defined becomes the only definition of that class. Subsequent definitions loaded into that application domain are ignored.

Sub-applications that are in child application domains of the main application can communicate with the main application. They have the highest level of possible interoperability with the main application. This situation is typical of a large application that is not multi-versioned, and it is the default behavior for the SWFLoader.

The current application domain

If you load a sub-application into the current application domain (rather than a separate, sibling application domain or a child application domain), the sub-application’s class definitions are often ignored. This behavior is because the first definition in a domain is used. Subsequent definitions loaded into that domain are ignored. If new class definitions are added, the main application can use them.

Using the current application domain is typical of RSLs and other specially compiled resources, and is not typically used when loading sub-applications.