Rather than going into any detail regarding my thoughts surrounding Apple’s updated iPhone developer license clause last week, I instead prefer to focus on the more exciting and positive developments the future has to hold for the Flash Platform in the mobile space; and at the moment, it’s Android

As you may be aware, beginning with Adobe Flash Player 10.1, the AIR 2.5 for Android SDK and Android, the Flash Platform will now begin to close the gap in terms of developing and deploying Web, Desktop and Mobile applications. Thus it appears this could open up some very exciting possibilities in the RIA space as, a write-once, deploy-anywhere solution for Mobile, Web and Desktop applications is obviously highly desirable.

For those of you unfamiliar with Android, it is a premiere software stack for mobile devices which provides an Operating System built on the Linux kernal, a very well designed middleware layer and core applications including an E-mail client, SMS program, calendar, maps, browser, contacts and more. Android also provides an Application framework, a Dalvik virtual machine which is optimized for Mobile Devices, an integrated web browser based on the widely known WebKit engine, SQLite storage, common Media support, hardware dependent Bluetooth, EDGE, 3G, WiFi, Camera, GPS, Compass, and Accelerometer support as well as many other features.

Originally developed by Android Inc., which was later acquired by Google, Android is now governed by the Open Handset Alliance; a consortium devoted to advancing open standards for mobile devices. Currently, over 50 mobile phones are expected to come shipped with Android in 2010. Moreover, Google and their hardware partners are now shipping 60,000 Android handset units each day! If this trend continues (which it certainly appears will be the case) this equates to over 21.9 million devices shipping with Android per year.

Traditionally, getting started with Android has been quite simple for developers who have experience with Java as one need only download and unpack the Android SDK distribution and install the Android Development Tools (ADT) Eclipse plugin. Managing different Android platforms as well as other SDK components is accomplished via AVD Manager which come with the SDK. As expected, the Android SDK also comes with a very high quality device emulator which feels similar to the BlackBerry JDEs device Simulators.

While developing applications for Android with ADT is certainly convenient (and quite fun), from a Flash Platform development perspective it is much more desirable (as well as economical) for developers to leverage their existing skill-set and APIs to develop a single application targeting Flash Player or the AIR runtime that will work with any device shipped with Android. And with Flash Player 10.1 and the current private beta of Android AIR 2.0, the Flash Platforms reach will now include the Android platform. The most significant of these new possibilities is the ability to develop a single application which supports both Web and Mobile devices alike. Thus considerably simplifying the development and deployment process. Of particular interest is the ability to leverage Mobile Device specific features such as Accelerometer, GPS, multi-touch, gestures screen orientation etc. from an AIR application.

Flash Player 10.1 will support devices running on Android that meet the minimum software and hardware requirements, which at the moment appear to be devices with an ARM v7 (Cortex) processor. Both Droid and Nexus One carry ARM v7. Architecturally, I am quite interested in seeing how this all comes together in terms of memory and cpu optimization.

Working in conjunction with Adobe, as part of the Open Screen Project, Motorola is helping to develop Flash Player 10.1 so it works on Android. Motorola will also be deploying the Flash Player broadly across its Android product portfolio going forward; releasing Flash Player updates for existing devices such as the Droid (which I happen be actively developing for).

Adobe is targeting the end of July 2010 to have the Android AIR 2.0 Beta and Flash 10.1 for Android available. For updates sign up for:

When developing application in Adobe AIR which utilize the SQLite API it is often useful to have a quality SQLite editor available, especially during development and testing.

I have tried many different SQLite editors, most of which were quite good, however the best of the bunch you have to pay for.

Personally I recommend SQLite Administrator. SQLite Administrator is a powerful tool which allows for the design, creation and modification of local SQLite databases. The code editor is very intuitive and provides a simple UI which allows you to write SQL queries with little effort. In addition, there are many useful features which you would expect from a quality editor such as code completion and highlighting.

So if you are looking for an high quality free SQLite Editor when working with Adobe AIR and SQLite check out SQLite Administrator

I have been working with the new SQL API for Adobe AIR which is available as of Flex 3 beta.

The new SQL capabilities provide numerous possibilities when developing online / offline desktop applications in Adobe AIR which require data to be persisted locally when not connected.

The SQLConnection and SQLStatement classes provide everything you need for working with a SQLite database. The SQLEvent and SQLResult classes provide an API into asynchronous statement executions from which query result and faults can be handled.

After initially working with the new classes I began to recognize the need for some interfaces which could assist in managing query results. With that being said I have created some straight forward interfaces which you can utilize to handle SQLConnection and SQLStatement results in order to handle SQLResults and SQLEvents uniformly.

The ISQLConnectionResponder interface defines a contract for classes that must provide an API which handles SQLEvent objects dispatched via a SQLConnection instance. The ISQLStatementResponder defines the contract for classes which must handle successfull SQLEvents dispatched via a SQLStatement instance. These interfaces are targeted at wrapper APIs for the SQLConnection and SQLStatement classes, therefore as a best practice they should be implemented in a has-a relationship design.

I am also in the process of developing an AIR specific ServiceLocator which integrates into the Adobe Cairngorm framework which will allow AIR application to utilizing the SQLite API to be built with Adobe Cairngorm. This will provide a temporary solution while we await a Cairngorm update which addresses this. As always I will publish the AIRServiceLocator as open source once completed.