Adobe AIR and HTML

Adobe AIR is currently in beta (with a second beta version rumoured to be released in October) and I thought it a good time to take a deeper look into things and see how easy it would be to develop an application with it. To do so, I decided to build Snitter.

Building for the web and desktop

My original goal was to build an application that could work well on the web and as a desktop application. I wondered how much overlap in functionality could exist between an AIR app and a web app and surprisingly, quite a bit. Much of the initial interface, in fact, was built as a web app first before moving to AIR. Once I got into the AIR environment, I found that some features weren't needed anymore, like the sound engine.

While I think I could have pulled it off, it turned out it wasn't as simple as that. The design approach is different and what is usable on the web becomes awkward in a desktop application (and vice versa), at least for this type of application.

In the end, I ended up dropping the web application side of things to focus on just the AIR application. From the limited people I surveyed, nobody said they'd use the web app version anyway (since, you know, Twitter is already a web site...do you need to go to a web site to use another web site?)

HTML by Webkit

Adobe AIR is essentially a Flash-based runtime that can load in different types of controls including PDF and HTML documents. HTML documents are powered by Webkit, the same engine that powers Safari. This means that you have a respectable rendering engine at hand. From what I can tell, it's a little better than Safari 2 but not as good as Safari 3, whether this will change by the time Adobe AIR hits 1.0 remains to be seen.

On top of that is an additional layer of operability that can be manipulated via JavaScript such as opening new windows, working with the local filesystem, sound and local database access.

From web app to AIR app, you can be pretty confident that the HTML will render as expected on both Windows and OSX...and one would assume Linux as well. (The Linux version of AIR is expected to launch a little while after the Windows and OSX versions.)

CSS Support

The CSS support, being Webkit, is good but being within a strict environment like this, I think they need to make it easier for developers to style elements and controls, much like Apple did with the version of Safari on the iPhone. Being able to easily render rounded corners and gradients would avoid having to load up the UI with multiple graphic files and would make applications more difficult to style.

The other interesting thing I ran into was creating a UI that automatically took up 100% of the application canvas. This goes back to my whole app vs. the web issue. On the web, you start from the top and work your way down. If the page is done half way down, it's done. But in a desktop application, elements (like the custom chrome) have to stretch the full height of the window. I stumbled with this until I remembered something I read recently (which, for some reason I can't find now): use position:fixed but set the top and bottom to 0. And just like that, everything started coming together.

All-in-all, the CSS support is what you'd expect and not having to deal with cross-browser rendering issues has been a real plesure!

UI Concerns

Adobe offers up lots of flexibility including the ability to wire up your own resize, maximize, minimize and close buttons while at the same time, choosing to turn the default application chrome off.

By turning off the default browser chrome, you instantly run up into a cross-OS dilemma: where do you place the controls? When I build Snitter, I used my Windows bias and placed the close button on the right. I may add in OS detection and place the controls accordingly. But it's just one more UI hurdle to handle.

Some are concerned that AIR this design flexibility opens the door for inconsistent UI with other desktop applications. While I think that most applications built in AIR will have a custom UI, the popular applications will be those that do it well.

I do think the widget movement has already moved people away from the default OS interface. AIR-based apps will do well to fit a niche between widget and full-blown desktop application.

My largest concern and probably the most common complaints about Snitter have been about how the UI currently behaves. The scrollbar doesn't interact with the mouse wheel, text selection is difficult, and speak nothing of how hideous some of the controls look. At this point, I feel like much of the focus has been on getting the API nailed down and Adobe has indicated that this will be addressed in the next beta release due out in October.

Development Environment

Adobe currently provides a few tools. The SDK comes with a debug application that can launch the application, allowing you to play with your application before having to package it. There's also an AIR extension for Dreamweaver, although I haven't tried it so I have no opinion on how well it works.

What I did do, is give Aptana a try. It has support for AIR and made developing my application a pretty painless process. I wanted to try Aptana to see if it might be a good solution for my day-to-day PHP and JavaScript development and while I haven't decided if that's the case, I'll continue to use it while developing AIR applications.

There's currently a lack of quality debugging tools, leaving you with trace and alert calls to access information. I anticipate new tools will be made available, making development for Adobe AIR an easier proposition.

Is it worth it?

Considering that October is just around the corner, the current UI shortcomings — the unattractive scrollbars, lack of proper text selection, and lack of wheel scroll — should be resolved. Once those issues are fixed, building AIR applications using HTML may be an easy way for many web developers to build desktop applications.