Key Differences in Air for Android and iOS Packager App Capabilities

Mobile Development, Tutorials Comments (10)

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.

Android Device Capabilities

AIR Android supported methods output on FroYo

iPhone device capabilities

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 Supported Supported
Capabilities.hasAccessibility Not Supported Not Supported
Camera.isSupported Supported Not Supported
CameraRoll.supportsAddBitmapData Supported Supported
CameraUI.isSupported Supported Not Supported
ContextMenu.isSupported Not Supported Not Supported
DatagramSocket.isSupported Not Supported Not Supported
DNSResolver.isSupported Not Supported Not Supported
NativeApplication.supportsDockIcon Not Supported Not Supported
NativeDragManager.isSupported Not Supported Not Supported
DRMManager.isSupported Not Supported Not Supported
EncryptedLocalStore.isSupported Not Supported Not Supported
Geolocation.isSupported Supported Supported
HTMLLoader.isSupported Not Supported Not Supported
IME.isSupported Not Supported Not Supported
LocalConnection.isSupported Not Supported Not Supported
Microphone.isSupported Supported Not Supported
NativeApplication.supportsMenu Not Supported Not Supported
NativeApplication.supportsDefaultApplication Not Supported Supported
NativeApplication.supportsStartAtLogin Not Supported Supported
NativeMenu.isSupported Not Supported Not Supported
NativeProcess.isSupported Not Supported Supported
NativeWindow.isSupported Not Supported Not Supported
NativeWindow.supportsNotification Not Supported Not Supported
NetworkInfo.isSupported Supported Not Supported
HTMLLoader.pdfCapability Supported Supported
PrintJob.isSupported Not Supported Not Supported
SecureSocket.isSupported Not Supported Not Supported
ServerSocket.isSupported Not Supported Not Supported
Stage.supportsOrientationChange Supported Supported
StorageVolumeInfo.isSupported Not Supported Not Supported
NativeApplication.nativeApplication.systemIdleMode Supported Supported
NativeApplication.supportsSystemTrayIcon Not Supported Not Supported
XMLSignatureValidator.isSupported Not Supported Not Supported
Updater.isSupported Not Supported Not Supported

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.

Follow Float

» Mobile Development, Tutorials » Key Differences in Air for...
On October 8, 2010
, , , , , , ,

10 Responses to Key Differences in Air for Android and iOS Packager App Capabilities

  1. […] just posted a joint article authored with Erik Peterson there outlining key differences between AIR for Android and the iOS packager created applications. […]

  2. I have been developing for AIR on Android all throughout the pre-release and I’m looking to developer for iOS once I have completed my current project. This article clarified many things. Thanks.

  3. […] Key Differences in Air for Android and iOS Packager App Capabilities » Float Mobile Learning &… […]

  4. […] running on the MAX 2010 Hardware Developer Kit box. I figured it would be good to take the deviceTest Flash application used to test Android and iOS capabilities. I took the .fla file from Float […]

  5. Alexandru says:

    Excellent work! Thanks!

  6. Radu Cocieru says:

    Small addition.
    PDF capabilities should be tested with: HTMLLoader.pdfCapability==HTMLPDFCapability.STATUS_OK

    HTMLLoader.pdfCapability is 0 if the PDF is available and gives an error number otherwise.

  7. Renaud says:

    Radu Cocieru is right, I tried to use the HTMLLoader.pdfCapability on Android device and it returns HTMLPDFCapability.ERROR_INSTALLED_READER_NOT_FOUND.
    But I have Acrobat reader installed on it.
    HTMLLoader.pdfCapability is supported but there is no acrobat reader plugin for HTML on Android

Leave a Reply

Your email address will not be published. Required fields are marked *

« »