Cross-Application Interactions in UcompOS Implementations

One of my primary goals in the design of the UcompOS Rich Productivity Framework was to create a flexible environment for the deployment of multiple Rich Internet Applications that needed to work either separately, or discretely to create a singular overall rich experience.

UcompOS Applications launched by the UcompOS Portal are sandboxed in such a way that they exist as isolated entities that can operate independently from the environment they’ve been loaded into.

As I touched upon in my posting on Building Drag and Drop Experiences in the UcompOS RPF, UcompOS applications should not attempt to access other UcompOS entities directly through direct ActionScript or JavaScript class/method interaction.

This is not to say that you cannot do this, but if you were going to, say, load two separate UcompOS entities into a n0n-sandboxed configuration, and have each entity access the other’s classes, you would obviously be tightly coupling the entities in such a way that if two different developers were working on each entity, one could very easily break the implementation unintentionally.

If you have a very compelling reason to do this, I have not prevented you from doing this.

In this posting, I will touch upon some of the numerous models for achieving cross-application interactivity in the UcompOS RPF.

Proxy Components and Services Dictionaries

The model for interactivity across the boundaries of UcompOS entities and applications is to use the framework that’s built into the UcompOS SDK, mainly Services Dictionaries and Proxy Components.  These are two extremely important concepts to understand, which is why I touch upon them so frequently.

In review, a Services Dictionary publishes a list of the “Public API” methods that an entity exposes to other entities.  A Proxy Component is a client apparatus in one entity that is built to connect to the Public API method sponsored by some other entity.

As I’ve also explained numerous times, and particularly in this posting, the UcompOS SDK has a number of Proxy Components built into it that are client apparatus’ to the Public API methods of the UcompOS Portal.  After all, the UcompOS Portal is simply one entity in the overall context of the UcompOS Continuum.

Numerous postings and tutorials I’ve posted give examples of building Services Dictionaries and Proxy Components so I won’t go into the details of this in this posting, but again, understanding their mechanics is crucial.

UcompOS SDK Events

Another crucial concept to understand in the UcompOS RPF is its Event-based implementation.

By strict convention, all Proxy Components extend a class in the UcompOS SDK named AbstractProxyComponent.

As the name implies, it is an abstract class and should never be instantiated directly, only extended.  (Unfortunately, ActionScript 3 doesn’t give us a true foolproof way to enforce abstractness.)

AbstractProxyComponent extends EventDispatcher so thus all Proxy Components inherit an addEventListener(); method.

So essentially, in one UcompOS entity, you can build a Proxy Component that talks to the Public API method in another entity.  And you can register an event listener to receive event notices from that Proxy Component.

That’s why I call these things “Proxy” Components.

You are creating a virtual representation in one entity of a physical implementation in another entity, so essentially, your Proxy Component is a “Proxy” to the true implementation that is actually located in an entirely different entity.

So when you do something like the following:

var w:UcompOSWindowProxy = new UcompOSWindowProxy();

w in the above scenario is an instance of the Proxy Component UcompOSWindowProxy that is built into the UcompOS SDK.

w is not REALLY the window that gets created on the UcompOS Portal, but it is a virtual representation of it.

But when you add an event listener on the CLOSE event of the window, it is as if you are attaching an event listener to the actual window itself.

I am hopeful that the concept of Proxy Components is making more and more sense to the dedicated readers of this blog.

The event handlers implemented with any Proxy Component are exclusively dispatched an instance of the SDKEvent class.

The SDKEvent class is worth studying.

If you look at the AS3 docs for the SDKEvent class, you’ll notice it has a collection of read-only properties.  One of which is data and another is proxyComponent.

By strict convention, any Public API method in a UcompOS entity returns an item of type Object.  This data is carried back to the Proxy Component that invoked the Public API Method in the form of an SDKEvent instance.

So for instance, building to our simple example above, I could do something like this:

private function windowInfoHandler(event:SDKEvent):void
 // this will be the Object returned by the Public API method I contacted
 var data:Object =;
 trace("Window size is "+data.width+" x "+data.height);

Let’s talk a bit about the proxyComponent property of SDKEvent instances.

It is of type IProxyComponent.

The AbstractProxyComponent event implements the interface IProxyComponent from the SDK, so any Proxy Component can be cast as an item of type IProxyComponent.

Dispatching an Event to a Proxy Component from a Public API Method

So you have built your Public API method and you have set up a Proxy Component in another entity to connect to this Public API Method.

As I have explained, the Object your Public API Method MUST return will be returned to your Proxy Component packaged in an SDKEvent instance.

But what if you asynchronously want to dispatch an SDKEvent to a Proxy Component?

The key to this is the BroadcastEvent class in the SDK and its static dispatchEvent(); method.

As an example of when we might use this capability, suppose we have a UcompOS AIR application that sponsors a Public API Method that allows us to asynchronously return the list of files in a directory.

The implementation of this might look something like this:

private var _uuid:String;
public function getFilesInDirectory(data:Object):Object
 _uuid = data._dataPackage.uuid;
 var directory:File = new File(;
 return SDKEvent.VOID;
private function getFilesInDirectory_handler(event:FileListEvent):void
 var files:Array = [];
 for(var i:uint = 0;i<event.files.length;i++)
 files.push((event.files[i] as File).name);

As a brief aside, notice in the Public API method, I am returning SDKEvent.VOID.  This actually suppresses the return altogether of any data to the calling Proxy Component.  This is the best practice when your Public API method doesn’t return anything of value to the calling Proxy Component.

When the UcompOS SDK passes the input Object to a Public API method, it adds a property to the Object called _dataPackage which itself is an Object.

This Object has a property, uuid, which is the same value of the uuid property on the Proxy Component that originated the transaction with the Public API method.

The BroadcastEvent.dispatchEvent(); method expects this uuid value as the first input parameter.

A Proxy Component that invoked this Public API method could have an event listener listening for events of type “fileListing”.  In this scenario, the event handler would be dispatched an SDKEvent with the data dispatched to the BroadcastEvent.dispatchEvent(); method.

Dispatching Continuum Events

The UcompOSGlobalManagerProxy class in the UcompOS SDK has a method named dispatchContinuumEvent();.

It accepts two parameters – the type of event, and a data Object.

When you call this method, you are dispatching an event to every entity in the UcompOS Continuum and the event can be listened for on the UcompOSGlobalManagerProxy Singleton.

So for instance, you could say something like:


And in an entirely different entity, you could do something like this:


and your event handler could look something like:

private function eventHandler(event:SDKEvent):void 
 trace("Your name is ";

The dispatchContinuumEvent(); method doesn’t need to target a specific entity as the BroadcastEvent.dispatchEvent(); method does – it simply dispatches an event to EVERY entity.

Launching one UcompOS Application from Another Entity

The UcompOSGlobalManagerProxy class has a launchApplication(); method which accepts as input an Application Manifest URL as a String.

This enables you to launch a UcompOS Application from another entity.  Similarly, there is a quitApplication(); method as well as a getConnectionId(); method which can be used to find the connectionId of an already running UcompOS Application.

UcompOS Shared Objects

As I posted here, the UcompOS RPF now has a Shared Object implementation where an entity can house Objects of specific names on an Object on the UcompOS Portal that is available to all other entities.

When any Shared Object is created or its properties are updated, a Continuum Event is dispatched.

This creates an environment where the Shared Object itself can become a useful medium for achieving inter-application and inter-entity communication.