Native Android Development Or Adobe AIR?
blog.theflashblog.com
blog.theflashblog.com
Native UI Controls There are many native UI controls available in the Android SDK. Most of the applications on the market make heavy use of these. They range from buttons, lists, form controls, layout containers, and much more. If you develop your application using Adobe AIR you will NOT have any access to these controls. The best thing you can do is to try and fake them, but from my experience it is never quite as good. So if you want to use native controls then you must go native.
That, in my mind, sums up why you would never use AIR for anything. I've tried out a number of AIR apps over the years, and have promptly uninstalled them all after a short period of time. They don't look like native apps, and they don't act like native apps. An example: on Windows systems (which I have to use at work), hitting CTL+Backspace deletes the previous word. In AIR? It inserts a control character.
Bottom line: If you want to write an app for a platform, write the app in that platform's native toolset.
It is interesting that in a lot of cases you would likely not even know an app was built on AIR with mobile. There are a good number in both the Android and Apple stores.
Adobe has done some really strong optimizations in the last year to enable Flash to perform on mobile devices. This has the side effect of a lower footprint on the desktop as well.
I mean, you can place a WebView in your application, and presto, you've got an HTML/Javascript based UI with all the access you want to native APIs: http://developer.android.com/resources/articles/using-webvie...
The reason people don't do this is because you don't want HTML, you want native controls most of the time (God, I hate UIs that try being different) and you also don't want your stupid app that fetches content from the web to flicker on screen transitions.
And why is this article giving reasons for the native API? Do they think AIR is appropriate for everything else? What else remains that couldn't be handled by a web page rendered in the browser?
I know several people that develop Flash and get an Android app for "free" with Air. It isn't really a matter of Air doing something that you can't accomplish with a web page in a browser. I see it as making use of existing assets/skills.
Air's selling point was that it enables the use of web-specific skillsets for making a desktop application. A strong accent has been placed on HTML + Javascript, because it has a lower barrier to entry (lower cost) then Flash / Flex (I know because I worked there).
On a regular desktop this makes lots of sense, since Air also takes care of the distribution / updating of an app (i.e. making it almost as painless as using a web app).
> get an Android app for "free" with Air
You mean they'll get a shitty app for free: even web applications are optimized for mobile phones, even for specific architectures with stuff like: http://jqtouch.com/ (for the iPhone)
Flash devs also know Html+Javascript. On the iPhone it takes a couple of meta-tags to make it behave more like a native app (loading screen / no address bar). Add to that HTML5 capabilities that you can take for granted on Android/iOS (geolocation, local storage).
The app store / os takes care of updating native apps (that in the case of Android at least, can have an UI made with web technologies).
So again, what does AIR offer?
(really, it's not a rhetorical question, I'm curios as they probably worked really hard on it)
> Flash devs also know Html+Javascript.
This is not true. I am incredibly inefficient with html/css/js. I can rapidly create quality applications with Flash. My guess is that I am not unique in that regard.
> So again, what does AIR offer?
It offers clear wins for some people. You aren't in that group, which is fine. The Flash development community is excited about it and making use of it as we type. Arguments for or against preferred technologies doesn't change that.
> HTML + Javascript ... has a lower barrier to entry (lower cost)
Both are zero in terms of cost.