Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

Share this Page URL
Help

Chapter 1: Developing and loading sub- a... > Developing sandboxed applications - Pg. 30

USING FLEX 3.2 31 Adobe recommends not sharing data models and other singletons with untrusted applications. For more information, see "Bootstrap loading" on page 45. Optimizing loaded applications When creating main applications and sub-applications, try to have as little overlap in class definitions as possible. In other words, try to have only one definition of each class so that the aggregate size of the applications is as small as possible. SWF files can be large, especially if they contain embedded assets or use many class libraries that are linked into them. If you are sure that the main application and the loaded application will always be compiled with the same version of the Flex framework, then you can externalize overlapping assets by using RSLs or other techniques with the compiler. In general sub-applications must load their own RSLs. You typically do not compile a sub-application against the main application's RSL or another sub-application's RSL, or even if you do, the sub-application will load the RSL on its own when it starts. The result is that the RSL is loaded twice, which likely negates the benefits of using RSLs. When you develop sandboxed or multi-versioned applications, you cannot always externalize overlapping class definitions, because the class definitions might be different. For example, if two applications are compiled with different versions of the Flex framework, then each application must have its own definition of the manager classes (such as the LayoutManager or the CursorManager) and other classes in the framework. As a result, do not externalize those classes by compiling the applications against the same RSLs. In previous versions of Flex, you were required to initialize certain manager classes such as the FocusManager if you loaded a module or sub-application into a main application that did not use those manager classes. You are no longer required to do this if you load the sub-application into a sibling application domain where each application has its own class definitions. However, each security domain must include a definition of the PopUpManager class in case an untrusted sub-application displays a modal dialog box. For information on externalizing overlapping assets, see Externalizing application classes. Developing sandboxed applications Sandboxed applications contain sub-applications that are loaded into separate security domains. By definition, they are therefor loaded into separate application domains as well. As a result, they can be multi-versioned, but are untrusted. Because they are untrusted, their interoperability with the main applications is limited. Types of sandboxed applications include portals, mashups, and dashboards. If you are using any third-party applications, you should load them as sandboxed applications. In addition, if you are using multi-versioned applications that use RPC classes or DataServices-related functionality, you should also consider loading them as sandboxed applications. Otherwise, you might be required to provide additional code such as a bootstrap loader. In a sandboxed configuration, loaded sub-applications are typically not on the same domain as the main application. This means that the applications might not necessarily trust the loaded applications by default. In addition, all sub- applications are not necessarily always visible at the same time, so the main sandboxed application must be able to load and unload sub-applications at any time.