I say ‘mostly’ since, in fact it is perfectly possible to embed Adobe’s Flash player into a standalone application written in C#, say, or Delphi and program its behaviour using Adobe’s Flex framework. But AIR applications don’t need to be embedded into other programs in order to operate ‘standalone’. They can be packaged up inside AIR-powered windows so that, in principle, an AIR application can be completely self-contained.

Native Desktop Integration

The advantages of AIR will vary according to who you ask, I guess. here is my own list:

 AIR apps look nice (when using Flash graphics for the front end)
 AIR apps are cross-platform
 AIR apps may be partially compatible with Flex apps. In other words, you can share much of the same code-base across standalone (AIR) and browser-embedded (Flex) applications.

For a more complete comparison of Flex (browser) and Flex (desktop) applications, see Adobe’s Feature Matrix: http://www.adobe.com/products/air/comparison/. For detailed information, visit the Adobe AIR Developer Center.

Adobe AIR applications support native desktop integration, including clipboard and drag-and-drop support, local file IO, system notification, and more.
(The Adobe AIR Developer Center)

So, to summarise. Flex apps generally run in the browser and do not have access to all the features of your operating system. AIR apps run standalone and have access to all the stuff you’d expect in any regular desktop application. Or anyhow, that’s what I’d assumed they’d do. Heck! that’s what Adobe says they do. Go to the Adobe AIR Features for Flex development page and click ‘Desktop Behaviors’ to listen to this summary: “During installation, an AIR application is connected to all of the operating system hooks for native applications including the Task Manager, Program Files and Start Menu or Dock. In both Windows and Mac OS, AIR applications ...behave like standard desktop applications.”

“All of the operating system hooks ... behave like standard desktop applications...” - that means an AIR application should let me do all the same stuff I can do in Delphi or C#, doesn’t it?

Well, no, as a matter of fact, it doesn’t. Though it took me a while to figure that out.

Drag, Drop and... Um...

When I started programming with AIR I ran into an unexpected limitation quite early on. The application I wanted to write was going to be a program launch pad - an AIR equivalent of a Delphi program I had written previously. My plan was to let users select an item (a program or a file) in the Windows Explorer, then drag and drop it onto the AIR app. When the item was dropped it would create a button and attach to it an on-click event handler which would launch the dropped item when the button was clicked. This seemed to me to be about the simplest useful program that would test the fundamentals of AIR’s native OS integration.

I programmed the drag and drop behaviour is next to no time, thanks to AIR’s NativeDragManager class. Having completed a drop event, it was trivial to retrieve the file name that was selected when drag event was initiated and to create a button which displayed that file name. All I needed to do now was to add an event-handler to launch that file.

That’s where I ran into problems. The traditional way to launch a native application on Windows is to call the API’s ShellExecute (or ShellExec or some equivalent function according to which language/library you are using). But AIR doesn’t have a ShellExec. That omission, I confess, surprised me. It surprised me so much, in fact, that I contacted Andrew Shorten (Adobe Platform Evangelist) to verify that it really wasn’t there, that I hadn’t just somehow missed it.

“You are correct in that there is no supported way of launching desktop applications within AIR,” Shorten told me, “The primary goal of the AIR runtime was to enable web developers to build applications that could be deployed across different operating systems; with that in mind a decision was made to ensure that features in AIR, wherever possible, help the developer to create applications that will run successfully on Mac, Windows and Linux with consistent behaviour. Our concern, during the development of AIR 1.0, with launching native applications or indeed running native code on a particular OS was that it might place a dependency on an AIR application such that it only runs on Windows or only on Mac - i.e. Where the necessary native application or code is present. We want end-users who download AIR applications to have a great experience, regardless of the operating system that they are using.”

So AIR apps are not comparable with regular standalone apps at all then?

“There is a subtle difference between creating a platform for developing desktop applications and creating a platform that enables web developers to deploy rich internet applications to the desktop,” Shorten says, “We’re focused on the latter and so hence the lack of native integration.”

Now, I can (kind of) understand the rationale behind excluding OS-specific functionality in order to make AIR ‘OS-neutral’. Then again, when the OS you happen to be using is as dominant as Windows, the developer may justifiably adopt a certain arrogance in regard to other platforms. After all, when you have unrestricted access to all the features of Windows using C#, C++ or Delphi then why on earth would you choose a technology that has so many restrictions?

OK, so for the sake of argument, let’s assume that it is your overriding desire to create cross-platforms apps with a Flash front-end and that everything else is of secondary importance. In principle, AIR should be the perfect technology for the job. In fact, Adobe’s other framework, Flex, is capable of going ‘more native’ than AIR itself. It is possible, for example, to embed Flash into a Win32 or .NET application and then use Flex’s ‘external interface’ to interact with the operating system. That includes doing things that are supposed to be AIR specialities (such as ‘native drag and drop’) as well as other things that AIR point-blank refuses to do (such as ShellExec). Well, maybe I’m too dim to see the big picture here - but having a new framework optimised for native integration which is able to do less native integration than the old framework which isn’t optimised for native integration seems to me to be just the teensiest bit, um, well, eccentric...

Unfortunate Limitations?

I get an impression that I may not be the first person to convey to Adobe my less than positive feelings on this matter. Adobe Rich Internet Application Evangelist, Ryan Stewart, has blogged about one ‘hack’ to get around the lack of ShellExec on his blog. Meanwhile, Mike Chambers (Principal Product Manager for Developer Relations for Adobe AIR) writes on his blog: “Two of the most requested features for Adobe AIR have been the ability to launch native executables from an AIR application, and the ability to integrate native libraries into an AIR application.” He goes on to say: “Unfortunately, neither feature will be included in Adobe AIR 1.0.”

I can’t persuade anyone at Adobe to tell me whether they will be in AIR 2.0 but I presume that the word ‘unfortunately’ in the above was not accidental. At any rate, Chambers already has a ‘proof of concept’ workaround for the omission of ShellExec.

My initial impressions of AIR are, then (how can I put this politely?), ‘mixed’. I like the fact that it supports ‘native’ interoperability including things such as drag-and-drop and file operations. And I like its ability to use Flash for the user interface. But I find it bizarre that important native functionality has been deliberately excluded. I would be able to understand if this had been provided as an option; I would have no objection to having the choice of signing applications as either ‘secure’ (cross-platform with restricted native access) or ‘insecure’ (the whole Monty). What I cannot for the life of me figure out is why Adobe thinks that developers with so many other choices available (not least of which being Microsoft’s cross-platform would-be ‘Flash-killer’, Silverlight and its bigger brother the Windows Presentation Foundation) will be prepared to embrace a technology with such dramatic restrictions.

Let me be plain. I like Flex. I think Flash is a great way to define user interfaces. In principle, AIR sounds like a fantastic way for Flash to break out of the browser and onto the desktop. But unless Adobe removes its serious limitations, I won’t be developing AIR applications myself.

I am much more interested in developing Flax applications, however, since (weirdly) Flex allows me to program applications with much more complete native integration than AIR. True, it doesn’t go out of its way to make it easy to do - but all the same it can be done.

I’ll be explaining how to get started with Flash and AIR development in a series of articles here on Bitwise shortly. Follow along and make up your own mind.

Also On Bitwise
 Flex - the road to Web 3...? (Adobe interview)
 Silverlight, Flex and the Future of Web Applications (Multidmedia interview)
 Microsoft Silverlight for Rich Internet Applications (Microsoft interview)