Having developed a few Adobe AIR applications now (Memory, facedesk, GMDesk), and having talked to some people of the Adobe AIR Team, I thought it was time to express my feelings on what it’s like developing with Adobe AIR.
My idea is to list the things I like respectively the things I think need improvement or I outright dislike. The not-so-god parts is probably most interesting, since it contains a few things which would refrain me from using Adobe AIR.
Installing AIR applications on different platforms, both through the installer badge (I’ve only used the beta AIR Badge) and from an
.air file has worked great. I’ve tried it on Windows Vista, Windows XP and Mac OS X.
Once installed, it looks and behaves exactly the same (with an exception I’ll get to later on).
Once I decided to get started, it was very easy to develop one’s first test application. Following these steps, found in the good, but overall sparse, Developing Adobe AIR Applications with HTML and Ajax, anyone should be up and running within a very short time:
Hello World, AIR-style
After that, I went through the Creating your first HTML-based AIR application with the AIR SDK, which helps you setting up the necessary files, and then explains how to test the application, create an installation file and how to manually create certificates.
Good stuff, and as you know, as soon as your first Hello World is out the door, there’s nothing to beat that feeling of accomplishment and being on the path to great things!
AIRAlias.js file, you have very easy and complete access to everything exposed to an ActionScript Developer. This is great, and offers a way to create truly compelling things.
Hand in hand with that, you can very easily access the user’s computer and write/read files etc.
Adobe AIR Developer Center for HTML and Ajax
The Developer Center is filled with articles, explanations and good links. Probably a good start for most things you might be looking for.
Adobe AIR Marketplace
The Adobe AIR Marketplace is a good place to have your applications seen, and get a first round of users.
What isn’t good
At this time, however, I have to bring up my main problems and objections:
The way the application installer is presented to your end users is in a dialog which uses certificate technology to detect if the publisher of the application is trust-worthy. If the certificate isn’t issued by such an authority, but rather a home-brewn one, the dialog will have two scary looking icons and a text which is bound to discourage anyone (at least most people) from installing the application.
I do understand the reasoning behind this, but the implications are terrible! As it is, only companies have the right to get certificates (or re-use already existing ones), meaning that no private developer will ever be able to deliver an application that seems to deserve any trust. Just imagine how this is a showstopper for all kinds of people wanting to deliver great applications on a promising platform, but the platform itself tells the end users that it isn’t safe to install it.
While the certificates are there to protect the end user, Adobe has to, some way or another, step in and relieve the developers from the burden of proving that the application is ok. I mean, Apple will offer that possibility with iPhone App Store, and Adobe could definitely add that to Adobe AIR Marketplace.
My suggestion is that any application released to the public should get the opportunity to go through an approval process with Adobe, to get Adobe to vouch for the application’s integrity and security. If this means that it has to be submitted to the Adobe AIR Marketplace, getting a green light, and then getting ready for the public, so be it.
But as it is now, the situation is unacceptable for any developer not being part of, or running, a company,
Pushing out automatic updates to the end users isn’t as easy as it seems nor as it should be. I’ve created a script to automatically update AIR applications, inspired by others, but it was far too much work.
I’d suggest that the
Updater object should itself have a method that just takes a URL to an
.air file, compare those two, and present a dialog to the end user telling them there’s an update and offering them the option to retrieve it right away or later. This could very easily be done by comparing the version number (given that it is number-based) in the application descriptor file or just plain datestamps of the
.air files themselves.
For those who want to create more elaborate updating schemes, fine, give them any possible option. But for most people who just want the runtime to do this for them and help them out, it has to become easier.
Lagging version of WebKit
The web browser in Adobe AIR is based on the WebKit rendering engine, which is fine (although it’s not my personal favorite). It is very fast, and things generally look ok. There’s a debugger available, AIR Introspector. To be honest, I haven’t used it much, but right off the bat I’d prefer Firebug any day.
What might become a risk, though, is that the version in Adobe AIR is very much prone to constantly be one version after the latest release of the Safari web browser (based on the same rendering engine). While I understand that Adobe might need to tweak it, this will lead to a situation similar to the one with Firefox and Mozilla web browsers being one version ahead of the Netscape releases; a situation no one wants.
Preferably, the Safari Team and the Adobe AIR Team should synchronize their releases, or there should be an option to push out a certain version of WebKit to your application users. Developers don’t want to get more worried about how certain features work in just a specific framework’s version.
Web browser sniffing
This really isn’t Adobe’s fault, but since it uses WebKit, it will render the pages the same as Safari. However, in the
navigator.appName properties only the text “WebKit” is available, and no trace of Safari.
While that is actually correct, many web sites use web browser sniffing; think Google, Facebook etc. Generally, this is a bad practice and those instances should have been based on object detection instead (except for the few times where web browser detection is unfortunately a necessity).
So, while Adobe is doing the right thing, the real world isn’t really adapted to it. And, it would be much easier for Adobe to have talks with at least some of the most popular web sites to find a common ground, or to add something like Safari to its value (although it would be incorrect), than just hoping everyone in the world creating web sites will start writing better code. But, as long as the situation stays like the current one, Adobe AIR will offer a Safari-cloned web browsing experience, but it might not always get that treatment.
I think that creating any kind and sort of mash-ups is an important factor for gaining popularity for both the involved web sites and the Adobe AIR framework, and I do hope Adobe will look into what they can do here.
Even more focus on “regular” Web Developers needed
Just imagine winning the bulk of them over!
I really don’t know why, but form fields look dog-ugly in Adobe AIR applications. Especially
select elements seem to have gotten a beating by the ugly-stick. And what’s even worse, it doesn’t have a system-native look in any of the operating systems.
To me, this is a capital error. Aside from just looking bad, it’s about user recognition and how easy-to-use and familiar the experience is to them. Also, with
select elements, they seem to get an extra space at the bottom of them when running applications on a Mac, while at the same time not having that space in Windows.
Really, when in Rome…
Adobe AIR offers a very promising future for creating great Rich Internet Applications. The certificate situation has to change, and some of the above-mentioned issues need tending to; at the moment, it is apparent that it is a 1.0 release, and a number of things can definitely be made easier or just plain better. It’s a good start, though, and if Adobe listen to developers, this can become something really good!