I started writing a lengthy comment in response to brother Kevin Suttle‘s very concise and well-written celebration post on the announcement of AIR for Android and Mobile. Please read that first here: http://kevinsuttle.com/2010/02/15/air-mobile-will-spark-the-era-of-contextual-applications/
In response to that post and many other announcements today, I have a lot of thoughts and questions I’d like to
air out post. Before I get into this, I feel the need to state now that I love AIR. I’ve loved building AIR apps, coding with both CS4 and FlashBuilder. I am thrilled that Adobe is pushing this further into the mobile realm and hope the adoption skyrockets! I think it is the future of the Flash platform.
And now, some of my thoughts/questions and issues:
A. Aside from the use of a common language and platform in Flash, how can/will building AIR mobile apps be a unified advantage over building native apps on the device? As Ryan Stewart noted, “Depending on the device, you may want to make some small modifications, but you’ll be able to reuse your assets and a bulk of the code to quickly create cross-platform mobile applications with AIR mobile.” As we know some of the pave-over pitfalls of building AIR apps across Mac and Windows, there are some conditionals required to handle things like docking and alerts. My hope is that Adobe can continue to offer more seamless pave-over/common solutions that will let us tap into unique device platform features with a unified code approach.
B. It’s hard for me to envision how the same windowing, alert and docking functionality I’ve implemented in a desktop-based AIR app will appear/function on a mobile platform and smaller screen size. Assuming the mobile device/platform implementation of AIR supports this, will they work in a familiar way so the user knows how to handle them? Example: Twhirl. On Android, will the identical AIR app (if supported verbatim) actually load multiple windows for each of my Twitter accounts and lists? Will the app’s taskbar/docked icon (or mobile equivalent, if there is one) blink or bounce when I have a new tweet? Will a notification window popup over whatever app I’m using (or if/when I’m on a phone call) with new tweets? Hard stuff to imagine, but very exciting possibilities.
C. How will the AIR API proxy unique device functionalities like GPS, Accelerometer, orientation (landscape/portrait), touch/mult-touch, etc? Will we see separate classes for each, or something similar to the Flash Lite implementation of System.Capabilities.hasStylus? Furthermore, if I write such functionality into an app, will AIR ignore or intercept such calls if the same app is installed on a device without that functionality?
D. Most important (to me, anyway) of all, is the issue of distribution. There was an exchange earlier today between Ted and Scott about distribution and monetization. If AIR-built apps are to be listed in respective ‘app’ stores on different device platforms, will that require the developer to build/package the app for each device they wish to distribute too? Will there be a unified certificate or similar approach to protect source and assets from onedevice/store/platform to the next?
I’ve got more questions, but I’ll leave that for another post. Forgive me as I know the announcement is super fresh, and I’m sure many of these questions will be answered soon. My excitement has me desiring many answers and discussion now. If you have any thoughts or answers, similar or on other aspects, please post them and let’s get a dialogue going here. (Feel free to direct responses/comments to brother Kevin Suttle’s post.)