Loading Applications - About loading sub-applications

About loading sub-applications

Flex lets you load and unload sub-applications in a main application. Reasons:

• Reduce the size of the main application
• Encapsulate related functionality into a sub-application
• Create reusable sub-applications that can be loaded into different applications
• Integrate third-party applications into your main application
  

Level of interoperability

The way in which the sub-application is loaded defines the level of interoperability between the main application and its sub-applications. Consider the following factors when loading sub-applications in your main application:

Trusted applications What level of trust do the applications have? The higher the level of trust greater interoperability with the main application. In general, though, if you do not have complete control over the development and deployment of a loaded application, consider that application to be untrusted.

Versioning Are the applications compiled with the same version of the Flex framework? The default method of loading sub-applications assumes that all applications are compiled by the same version of the framework. However, Flex can load applications that were compiled with different versions of the framework. These applications are known as multi-versioned applications.

The level of trust and use of versioning are determined by the application domain and the security domain into which the sub-applications are loaded.

Types of loading

Single-versioned applications are guaranteed to have been compiled with the same version of the compiler as the main application. They have the greatest level of interoperability with the main application, but they also require that you have complete control over the source of the sub-applications.

Multi-versioned applications can be compiled with different versions of the Flex framework than the main application that loads them. Their interoperability with the main application and other sub-applications is more limited than single-versioned applications.

Sandboxed applications are loaded into their own security domains, and can be multi-versioned. Using sandboxed applications is the recommended practice for loading third-party applications. In addition, if your sub-applications use RPC or DataServices-related functionality, you should load them as sandboxed.

Sandboxed applications have the greatest number of limitations on application interoperability. These restrictions include the following:

• Stage Access to the stage from the sub-application is limited to some stage properties and methods.
• Mouse You cannot receive mouse events from objects in other security domains.
• Pixels Applications cannot access the pixels drawn in applications that are in other security domains.
• Properties While applications can get references to objects in other security domains, avoid doing this for security reasons. Some properties are restricted, such as the Stage or any parent of a DisplayObject that another application instantiates.

Note: multi-versioned and sandboxed applications must be compiled with the same or older version of the compiler the main application was compiled with.

Note: When compiling each of these types of applications (multi-versioned and sandboxed), you should include the MarshallingSupport class into the main application and sub-applications. You do this with the includes compiler argument, as the following example shows:
-includes=mx.managers.systemClasses.MarshallingSupport