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.
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.
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.