How UcompOS Flash/Flex Applications are Sandboxed in the UcompOS Portal

There are numerous paradigms for launching UcompOS Applications in the UcompOS Portal.

In many instances, the UcompOS Application itself will be a non-visual entity thought of as perhaps the Model and Controller in an MVC style implementation and then the UcompOS Application would launch individual sub-applications in UcompOS Window, UcompOS Browser Window, or UcompOS Artifact instances which could be considered the View in the MVC implementation.

A UcompOS Application can also be an AIR application running on the desktop launched by the UcompOS Portal and also, a UcompOS Application can be launched immediately into a UcompOS Window or UcompOS Browser Window instance by implementing specific attributes in the root of the UcompOS Application’s application manifest.

The specific implementation details of SWF-based UcompOS content being loaded as a UcompOS application or sub-application into the UcompOS Portal warrants discussion.

If you’re an experienced Flash/Flex developer, you may come to the UcompOS RPF with a pre-conceived idea about how things are implemented and how you would go about building rich experiences.

There are 3 different scenarios where SWF content will be loaded directly into the UcompOS Portal:

  1. The SWF content represents a UcompOS Application that is loaded into the UcompOS Portal run-time.  In this case the SWF content is a non-visual entity.  It gets loaded into a SWFLoader with its visible property set to false that is attached directly to the UcompOS Portal as a child.  This application then likely is involved with launching sub-applications into UcompOS Window, UcompOS Browser Window, or UcompOS Artifact instances.
  2. The SWF content represents a UcompOS sub-application that is loaded into a UcompOS Window instance.  In this case, the SWF content is a visual entity.  It gets loaded into a SWFLoader and the SWFLoader is attached as a child to a UcompOS Window instance.  A UcompOS Window instance is derived from a class that extends the MDIWindow class from the mdi package in the FlexLib project.  And of course MDIWindow extends Panel.
  3. The SWF content represents a UcompOS sub-application that is loaded into a UcompOS Artifact instance.  In this case, the SWF content is a visual entity.  A UcompOS Artifact is actually a VBox implementation that gets attached to the UcompOS Portal and then the SWFLoader is attached as a child to the VBox instance.  The UcompOS Portal is a Flex 4 application with the Halo theme compiled so that is how I am using VBox here.

Here’s the important thing to understand about the SWFLoader instances implemented in all 3 of the above scenarios.  They are implemented in one of two “sandboxed” configurations.

If you are creating a Rich Portal Application and your intentions are to load two separate UcompOS Applications into the UcompOS Portal and then do some sort of coding where your accessing something like FlexGlobals.topLevelApplication, this will not work.

All communication with other entities in the UcompOS RPF should be accomplished exclusively via the communication protocols in the UcompOS SDK using implementations such as Proxy Components and public API methods exposed in Services Dictionaries.

The goal is to keep the UcompOS Portal as “dumb” as possible and enable it to focus exclusively on being really good at its base core objectives which are:

  • An MDI (Multiple Document Interface)
  • Style and aesthetic presentation management
  • Artifact model for widget-like implementation
  • UcompOS Application run-time
  • Event Dispatchment architecture

The classes UcompOSArtifactProxy and UcompOSWindowProxy each have Boolean sandbox parameters.  Also, the root <application/> element in an application manifest has a sandbox attribute which accepts values of true or false.

The default condition if you don’t set the sandbox parameter is true.

From an implementation point of view, all SWFLoader instances attached to the UcompOS Portal have the trustContent set to true.  This may be something I rethink when moving the UcompOS RPF project to Beta but at least in my main UcompOS RPF application I am building, the domain that I serve the UcompOS Portal from will be the exclusive thing I serve from that domain as I am interested in creating the a strong degree of disaggregation. (Of course you should have a solid understanding of policy files (such as crossdomain.xml)).

In the case where the sandbox property is set to true (the default condition), the SWFLoader‘s loadForCompatibility property is also set to true.

This creates a situation where the loaded SWF application is loaded into a sibling ApplicationDomain relative to the UcompOS Portal SWF application.

The loadForCompatibility property addresses the need for a SWF to be able to load child SWFs created with different versions of Flex.

For instance, if you tried to load a Flex 3 UcompOS application or sub-application into the UcompOS Portal with its sandbox set to false, you’ll get run-time errors.

So then when or why would you want to load a UcompOS SWF application or sub-application with its sandbox property set to false?

Primarily only in instances when you wanted to implement drag and drop functionality across the boundaries of a UcompOS sub-application.

If all the drag and drop functionality is within the boundaries of the SWF, then the sandbox setting is irrelevant.

However, suppose you have two UcompOS SWF sub-applications loaded into UcompOS Window instances and you want to enable items to be dragged and dropped back and forth between them.  This would require you to set the sandbox property to false.  Also, this would require you to build your applications with Flex 4 (although I admittedly have yet to try implementing drag and drop across two different non-sandboxed Flash CS5-created applications).

In an upcoming tutorial, I’ll show a demo of building a UcompOS-based file management system like the one I have built for Educator 2 that enables drag and drop between multiple UcompOS Window instances as well as drag and drop from a UcompOS Window instance to a UcompOS Artifact instance.

The key fact to ascertain here is that strong command of the UcompOS SDK and how it is utilized to send information back and forth between entities in the UcompOS Continuum is compulsory to your developing the most powerful and effective Rich Experiences.