The UcompOS RPF and Adobe AIR 2.0

One of the more exciting features of the UcompOS Rich Productivity Framework is the ability for UcompOS Applications to exist as Adobe AIR 2.0 applications.

Therefore, the browser-based UcompOS Portal can launch and control these applications which are running on the desktop.  The implications of this are very exciting to me as we can implement a Rich Portal Application that gives us the best of a web application with basically full range of the Desktop to create whatever experience we want or need to.

Further, using the UcompOS SDK, a UcompOS Application can launch a UcompOS AIR application as a sub-application.

Over the next week or so, I’ll publish some tutorials that highlight some of the really cool things you can do with this capability, but clearly the key value-added proposition here is a portal continuum implementation that transcends the browser and extends to the Desktop.

I thought I’d start my AIR-related blogs with a technical discussion of why I have chosen to require any UcompOS AIR Application to be based on AIR 2.0 or greater versus the AIR 1.x versions that are now in production.

The UcompOS AIR SDK in fact will only work when embedded in an AIR Application created with AIR 2.0 or greater.  If you try to instantiate it, for instance, in an AIR 1.5.3 application you’ll get a compile error.

AIR 2.0 is in a state of public beta right now. You can download the runtime or the SDK at the following link:

http://labs.adobe.com/technologies/air2/

There are many advancements and new features that have been made in AIR 2.0 but I only really wish to focus on one of them here and that is the one that led me to make the decision I made which is to require at least AIR 2.0.

The capability I am speaking of is the new ServerSocket class.

Perhaps one of the most powerful advancements in Flash technology (in my opinion anyway) came way back in Flash 5 near the turn of the century with the ability for Flash content to make socket connections to a socket endpoint thus ushering in an era of bi-directional socket applications.  This has paved the way for Flash applications to extend to the realm of chat and IM clients, telephony-based applications, etc.

With AIR 2.0, in addition to the application being able to connect to a socket endpoint, it can itself serve as a socket endpoint.

The UcompOS SDK is what makes communication between entities in the UcompOS Continuum possible – specifically the SDKServer and SDKClient classes in the SDK.

Each entity that has the UcompOS SDK implemented – Flash, Flex, AIR, or JavaScript – is equipped to operate both as a server and a client in terms of its ability to receive as well as send commands from / to other entities in a particular UcompOS implementation.

The transmission framework in the SDK is based on the LocalConnection infrastructure of the Flash Player.  I chose to go this route because I was looking for something Lowest Common Denominator and LocalConnection has been around in the Flash Player for a very long time.

This would simplify the ability to use the same SDK in content ranging from ActionScript 1.0 through Flex 4.

When I went to implement my SDK in AIR Applications, I was confronted with some harsh limitations of the LocalConnection.

And I am not even talking about the limitation of being able to send no more than a 40 K chunks of data at a time – that limitation was easily side-stepped.

What I would find is that if you tried to send more than one SDK transmission at a time to an AIR application via the original LocalConnection strategy, the AIR application would cease being able to participate in any further LocalConnection activity until that application would quit and be restarted.  The ability for an AIR application to “queue” inbound LocalConnection requests seems broken and it seems that if a synchronous operation is processing in an AIR application and another LocalConnection request arrives during that time period, there is a total breakdown in the ability for the AIR application to participate in any further LocalConnection activity.

This apparently is a known issue and is said to be the case with any and all Flash-based content – running in the AIR runtime or in the Flash Player in the browser – however I have primarily only been able to observe this for myself with AIR-based content.

Obviously, this is unacceptable.  In an ambitious UcompOS implementation, you may have one AIR application that is being bombarded with requests from dozens of UcompOS Applications simultaneously.

With the limitations of LocalConnection, this would break down the Continuum and the ability for AIR applications to be a part of the Continuum very quickly.

I have engineered an alternative to LocalConnection to use in AIR applications at least for in-bound traffic.

When the UcompOS SDK is instantiated in an AIR 2.0 application, the application binds and listens on two ports – the first two available ports on the computer above port 1024 (though you can explicitly set these port numbers but more on that in another blog entry).

One port is used for validation purposes (as Flash Player socket activity is governed by very strict protocols these days) and the other is used for transmission of actual SDK messages.  Whether it is intentional or not I don’t know, but I never was able to get validation and SDK data transmission activity working on the same port so by strict convention I implemented the need for two ports.

In the SDK, if the destination of SDK activity is an AIR application, it automatically sends the message via a class in the SDK that extends Socket such that any in-bound SDK activity arriving to a UcompOS AIR Application arrives via the new ServerSocket capabilities in AIR 2.0.

Any other activity in the UcompOS Continuum leverages the legacy LocalConnection architecture of the Flash Player.

I have been very impressed by the durability of the ServerSocket architecture I have implemented here.  I have successfully transmitted very large files as ByteArrays from a browser-based UcompOS Flex application to a UcompOS AIR 2.0 application without any issues whatsoever.

LocalConnection is not without its issues however, but the UcompOS SDK has managed to sidestep most all of these issues.

So in summary, the reason I have chosen to require AIR 2.0 for UcompOS AIR Applications exclusively has to do with the introduction of the great new ServerSocket class.  However, make no mistake about it.  The great other new features of AIR 2.0 are definitely game-changers and I encourage you to check them out.

In the near future, I’ll post about UcompOS JavaScript applications and how I have implemented them into the UcompOS RPF.

About Edward Mansouri
Edward Mansouri is the CEO and Founder of Ucompass.com, Inc., a company focused on building scalable and profitable e-Learning enterprises. His expertise is in building e-Learning software, as well as in building visual frameworks such as the Enrich Content Enrichment System and the newly announced UcompOS Rich Experience Framework. He has been working with Flash since 1998, building Flash applications since 2002, and working with Adobe AIR since its private alpha release in 2006. He authored the site AIRApps.net (later renamed to O2Apps.com) dedicated to providing leadership in building Adobe AIR applications. In 2010, he is building and releasing a new e-Learning platform called Educator 2 which is built entirely upon the UcompOS Rich Experience Framework. Since 1999, over 1,000,000 students have taken courses served with his original e-Learning platform, Educator 1.

Comments are closed.