Posts in Category "mobile"

Yesterday we shipped the AIR 2.7 release. Although a relatively minor release in the grand scheme of things, this one is an important milestone for the Flash Runtime. It marks the culmination of an enormous effort over the past two years to bring AIR to mobile devices.

It has not been a straightforward path. Our first work targeted the first generation iPhone, which included a couple of major challenges. First we had to craft an alternate compilation strategy for ActionScript, since using just-in-time compilation, our usual strategy, was not permitted. Then we had to try to achieve reasonable performance on what was a slow device.

Further bumps along the way included scrambling to support the iPad, being forced off of iOS entirely, and switching our focus to the quickly-evolving Android platform. For all their similarities, Android and iOS often taken different approaches under the covers which made, and continues to make, the creation of cross-platform APIs a real challenge.

Of course, bringing AIR to iOS and Android wasn’t simply a matter of porting the code, either. We also added a variety of new APIs to accommodate the different features found in mobile devices. That list includes major additions like Geolocation, Accelerometer, CameraUI, CameraRoll, and StageWebView. Smaller enhancements supported screen orientation, soft keyboards, and other mobile-specific capabilities.

For me, the 2.7 release brings us to an important milestone. AIR is now clearly a viable platform for building applications across the PlayBook, Android, and iOS, with thousands of AIR-based applications available in various marketplaces. We’ve rounded out a basic set of mobile-specific APIs, and, with the iOS performance enhancements in this release, eliminated performance as a barrier to adoption. Moving to mobile was a mad scramble; now we’re there.

With 2.7 out the door, we’re shifting our attention from merely moving to mobile to pushing the envelope. That AIR is a cross-platform runtime is no reason for us to compromise on capabilities, performance, or tools, and you’ll see that in our upcoming releases. The technologies that will drive the next generation of AIR are already in the works, running here behind closed doors. We look forward to sharing these with you in the months to come.

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.