Archive for January, 2011

Approaches to Modular AIR Applications

As applications grow in size and complexity, it becomes necessary to break them up into manageable pieces. To some degree this can be handled at development time by maintaining a carefully-structured source code base.

Compiling the application into a single, monolithic deliverable may itself become a roadblock. For example, it may be desirable instead to compile and validate these pieces separately, and then assemble the resulting binaries. The pieces may be developed and shipped on different schedules, and thus different portions of the application updated independently. Or, the pieces may even be developed by other parties, as is often the case for applications supporting plugins. Regardless, it often becomes necessary to defer loading some of these pieces until runtime.

AIR currently supports two basic approaches for this kind of runtime assembly: Loading code into a network sandbox, and loading code into the application sandbox. The two approaches have different capabilities and different limitations. When designing large applications, it’s good to be aware of these trade-offs.

Network Sandbox

Code is loaded into a network sandbox via the Loader.load() API by specifying the URL of the target code. Code in this sandbox is restricted from accessing AIR-specific APIs, but has access to the same set of APIs that content running in Flash Player can access. The network sandbox essentially is Flash Player.

Interestingly, by restricting the API to the Flash Player API, the loaded content can necessarily be run in Flash Player or AIR. This may be especially useful if your application runs sometimes in the browser and sometimes in an application.

The API restrictions also mean that you don’t have to trust the code you load. The network sandbox prevent access to potentially dangerous APIs, such as the filesystem API. You can selectively open up access via the sandbox bridge capability.

Because the runtime knows where the code was loaded from, the code can use relative addressing to access other network resources, including additional network-hosted code. This allows for such code to easily be moved between different web servers, including between test and production environments.

The network sandbox is typically not suitable when the code your loading is supposed to function as an integral part of the application, with full access to other parts of the application and to the AIR APIs. For that, you want the application sandbox.

Application Sandbox

Code is loaded into the application sandbox via the Loader.loadBytes() API. Code in this sandbox runs as if it were installed along with your application, having full access to all of the AIR APIs. This facility provides the basic underpinnings for a complete plugin model. You can use that model to modularize your own application, or even open it up to third-party components.

Code loaded via this method is granted full API access, so it is essential that the application validates that it trusts the code before loading it. This can be accomplished in a secure fashion by using code signing, and validating the signature before loading the code. It may also be sufficient to obtain the code via a secure URL, but it should be noted that this protects the code only while in transit, and not after it is stored locally. To encourage secure use of this API, it loads the code, as the method names suggests, directly from a ByteArray and not from a URL.

Code loaded via this API does not retain its origin (URL), and therefore cannot access other code using relative URLs. Again, this was done to encourage secure use of the API. If this code can implicitly load additional code off the network, it is not sufficient to validate just the first SWF; each link of that chain requires careful validation.

Note that, because the origin of the code is removed, you can’t combine granting access to the application sandbox with the deployment ease of loading a SWF and associated RSLs from the network. If one module depends on another, some other referencing mechanism must be used.


It’s easy to imagine extending these models in a variety of ways. For example, while it is currently possible to create a plugin mechanism for an AIR application, the validation work has to be done by the application. This in turn prevents it from integrating with other runtime features, like RSLs. By expanding runtime support, we could potentially allow these features to work together.

We are actively exploring how AIR applications are using these techniques today, and how we might enhance our support for building large applications in the future. If you have feedback in this area, please let us know via a comment or via


For more in this area, you might want to read:

Replacing NativeWindow on mobile devices and TVs

The AIR NativeWindow API is a staple of desktop AIR applications, used to open multiple windows on the screen, each with its own stage. On mobile devices and TVs, the class is unsupported. So how does an application go about opening a window?

It doesn’t. On mobile devices and TVs, AIR applications can render only to the single available stage. The stage is automatically create and made visible when the application launches, and remains available until the application exits. In other words, it behaves essentially the same as the Stage does for Flash Player content.

Most code need concern itself only with the stage, and in this way can be made more portable between desktop, mobile, and TV deployment. For example, the stage directly provides information about its size. It also retains the ability to enter full-screen mode, and on mobile devices provides information about screen orientation.

If you have code that needs to check at runtime whether or not it can create new windows, simply check NativeWindow.isSupported.

Replacing Updater on mobile devices and TVs

Desktop AIR developers are, hopefully, familiar with our advice to implement an auto-update mechanism for your application first, even before you add your first feature. But what should you do on mobile devices or TVs, where the Updater API isn’t available?

On mobile devices and TVs, you should be happy that the platform has already implemented an update mechanism for you. As part of the better-developed application delivery ecosystem on these environments, applications are downloaded from application marketplaces of one type or another. These same marketplaces provide an update mechanism for these applications. Details vary as to whether the updates are installed automatically or require user intervention but, in any case, these will be the update mechanism users on these devices will be expecting.

If you need to write code that works in both places, you can check support at runtime via Updater.isSupported. This is a decision you might want to take into account earlier on, however, since there’s no value in including additional code, like the AIR Updater Framework, in applications targeting mobile or TV.

Replacing EncryptedLocalStore on mobile devices and TVs

If you’re familiar with the AIR desktop APIs and now looking at AIR on mobile or TVs, you may have noticed that the EncryptedLocalStore API is not currently available in either of these new targets. Here some tips on handling the situation.

First, consider whether or not the information your storing needs the additional security provided by the EncryptedLocalStore API. This is typically appropriate for items like passwords that need to be protected even from other software on the same device. However, items like configuration settings are best stored in a SharedObject or directly in a file.

Second, consider whether or not it’s appropriate to save this information on the target device without these protections. Unlike the desktop, mobile devices and TVs typically isolate all of the data stored by each application. A password stored on such a device therefore isn’t exposed to other applications, but can still be exposed if the device itself is compromised. Whether or not this is sufficiently secure depends on your application.

If the data is sensitive, and too sensitive to store without encrypted, you’ll have to fallback to querying this data from the user each time it’s required.

Finally, if you need to write shared code that can handle either situation, you can do so by writing a wrapper class that handles the switch at runtime. To perform a runtime check for EncryptedLocalStore functionality, simply query EncryptedLocalStore.isSupported.

More On Sharing HTTP Cookies with AIR Applications

In an earlier post, I mentioned that AIR applications can share cookies with the system browser, and this in turn can be used to share single sign-on (SSO) information stored in these cookies with an AIR application. Unfortunately, this turns out to be even less useable than I realized.

As I mentioned in the original post, there are clear limits to this capability. For example, it won’t work with browsers like Firefox and Chrome, as they don’t share the system cookie database at all.

On Windows, there are two system cookie databases: the default used by applications using WinInet, and a special, second location used by Internet Explorer’s protected mode. By default, most web sites visited will be visited in protected mode. AIR applications, as regular WinInet clients, still use the default cookie database. The end result is that cookies are not shared between the two.

This can be mitigated in some circumstances by changing certain IE security settings. For more details, see this Microsoft knowledge base article. Fundamentally, however, this is not a reliable solution for achieving SSO.

If you’d be interested in a solution that permitted this kind of cookie sharing, for SSO or other purposes, please let me know via the comments or at