Key Differences in Air for Android and iOS Packager App Capabilities

With the recent addition of Adobe AIR to the Android marketplace, and the reversal of Apple’s stance on using third party languages to develop iOS applications, you may wonder what this means to your development team. In recent presentations at conferences and clients, we have promoted using your existing toolkit to build for mobile. Many times that means building a web app that lives in the browser, but there are times that you need access to more features on the device. Adobe has developed a way to leverage existing familiarity with Flash and ActionScript 3 by providing both Air for Android and the iOS packager. This allows Flash experiences designed in CS5 to run in a native application environment rather than being confined to the browser (or in the case of iOS, not at all). Adobe has extended the ActionScript language to include mobile devices via some new APIs and in some cases these new classes support constructs that are mobile only. However given the nature of multiple devices on the market and the segmentation of the mobile OS market, each OS’s support of the ActionScript calls to the native device differ. This somewhat takes the shine off of the Apple (badum-tss), but nevertheless we applaud Adobe’s effort thus far to extend a familiar development toolkit to the smartphone world.

Once you dig in, you’ll notice there are some documented and well-supported calls available on both iOS and Android. Both support some very key features in employed in mobile development. Device accelerometers are supported which offers the ability to use the device as a controller for input based on movement or any other myriad ways that you may want to employ such a device capability in your application. The Camera Roll is supported for saving images into the device’s image gallery; this could emplyed for example, to save screenshots, bitmap manipulations and other graphics processing use cases.  Flash typically excels at this type of image processing. Geolocation, which is significantly more important on mobile than on the desktop, is supported on both platforms allowing for the identification of the user’s location based on gps or general wifi connection triangulation. Screen orientation is supported for switching between landscape and portrait mode. And controlling the system idle process to keep the device from dimming or going into a lock mode is also available. These features are surely advantages over the standard web app’s limited sandbox. On the downside of porting Flash output to these platforms, there are many things that are accessible on the desktop that are not accessible in a mobile context and a few that are enough different from each other that one must consider carefully the limitations when designing using these tools.

Upon further analysis, advantages lie with Android when comparing device capabilities. There are two key capabilities open to CS5 developers on Android that are not available currently available on iOS.  These are access to the Microphone and to the Camera.  Both of these inputs are very familiar to users and may seem missing when omitted from mobile apps. Our hope is that this limitation will be addressed on the inevitable update to the iOS packager for Flash, bringing these highly useful device capabilities to apps deployed on the iOS platform.

Another key feature enabled on Android is the NetworkInfo method which allows for identification of the types of networks available and being used by the device. This ability to tune the experience to match the users context more closely is used often in mobile design and having this limitation really makes producing an optimum experience for all users a much larger challenge.

Included below are images that test the capabilities of both platforms on a Motorola Droid device, an iPhone, and an iPad. These we created by using the attached FLA and running them out via their respective publishing workflows in Flash. In most cases the tests in the documents are simply checking the “isSupported” property of the element in question. Highlighted elements are enabled, grayed out elements are unavailable on their respective platforms.

AIR Android supported methods output on FroYo

iOS packager supported methods output on iOS 4.x

Take a look at this table to get a better idea of what this looks like (filled circles denote support, hollow is currently unsupported):

Capability	AIR for Android	iOS Packager
Accelerometer.isSupported
Capabilities.hasAccessibility
Camera.isSupported
CameraRoll.supportsAddBitmapData
CameraUI.isSupported
ContextMenu.isSupported
DatagramSocket.isSupported
DNSResolver.isSupported
NativeApplication.supportsDockIcon
NativeDragManager.isSupported
DRMManager.isSupported
EncryptedLocalStore.isSupported
Geolocation.isSupported
HTMLLoader.isSupported
IME.isSupported
LocalConnection.isSupported
Microphone.isSupported
NativeApplication.supportsMenu
NativeApplication.supportsDefaultApplication
NativeApplication.supportsStartAtLogin
NativeMenu.isSupported
NativeProcess.isSupported
NativeWindow.isSupported
NativeWindow.supportsNotification
NetworkInfo.isSupported
HTMLLoader.pdfCapability
PrintJob.isSupported
SecureSocket.isSupported
ServerSocket.isSupported
Stage.supportsOrientationChange
StorageVolumeInfo.isSupported
NativeApplication.nativeApplication.systemIdleMode
NativeApplication.supportsSystemTrayIcon
XMLSignatureValidator.isSupported
Updater.isSupported

Most of the items listed on this capabilities app are listed by Adobe as non-functional, so it is not a surprise that a verification of them does confirm that they are not available. Some capabilities that were listed as unavailable that do show up on the iOS devices are the NativeApplication’s isSetAsDefaultApplication which offers the ability to set this application as the default for opening certain types of files and NativeApplication’s startAtLogin which sets the app as an auto start when a user logs in. These, according to their test for support, do indicate that they are available, however, you cannot set the application to start on login and you cannot set this application to be the default for certain file types, so this seems to be a false positive.

Going forward, there are a number of items on our wishlist for the next generation of these publishing tools. Some of the elements that are missing from the active list would be nice to have in a mobile environment. The ability to trigger a notification with the built-in NativeWindow.notifyUser would be a very useful feature that seems to match fairly well with the notifications that are already existing on both mobile platforms. This would allow Air applications to access the notification stack and to cue up information right along side the natively built apps. Also, being able to embed an HTMLLoader inside of an mobile Air app would be a great extension and would allow many different combinations of web and AIR based apps to interact. This model of having HTML viewers directly in AIR is not foreign to the desktop version of AIR, so it stands to reason that this is likely on their radar as well. The current implementation of StageWebView is a good start, but has a lot of limitations that need to be addressed. The DragManager would seemingly also have some upside being able to handle drag and drop operations inside a mobile app but this may be duplicated with some version of touch/gesture events because of the nature of when the events get fired. One final nice-to-have would be the Updater class to grab newer versions of the application and install them on the device. This process would need some massaging to get to a path to find the update but finding a dynamic way to do in application updates would be ideal, especially on the Android platform, where users are more used to this sort of notification.

In conclusion, there are some rough patches in these cross platform APIs at this point, but overall, it’s a valiant effort and will certainly serve many Adobe platform developers. For more on the subject of capabilties for Mobile that CS5 offers you, check out this deck by Adobe Evangelist, Mark Doherty on Slideshare.

After looking that over, if you want to learn more about this topic, be sure to attend MAX, as Chad Udell, Float’s Solution’s Architect, will present on this topic at Adobe MAX on October 24th, 2010.