Adobe AIR, 10 Reasons to love it, 10 Reasons to hate it

I attended two days of briefings on Adobeâ€™s developer-focused products, especially the forthcoming AIR (Adobe Integrated Runtime).

In essence, AIR is the Flash player supplemented by additional features to enable applications that are not browser-hosted, but installed as desktop applications. AIR is great for some scenarios, weak for others. Hereâ€™s 10 reasons to love it:

1. Fast execution. ActionScript 3.0 has a JIT (just-in-time) compiler, putting it on a par with Java or .NET for raw performance.

2. Cross-platform. AIR apps will run on Windows XP and Vista, Mac OS X (PowerPC and Intel), Linux (though not in the beta).

3. Easy conversion of existing Flex or HTML applications. Itâ€™s the same basic runtime. In the case of HTML, AIR apps rely on WebKit, the core component in Appleâ€™s Safari web browser.

4. Easy installation. Provided the runtime has installed successfully, installing AIR applications is likely to be be trouble-free, since all the files go into the application directory.

5. SQLite. AIR applications have use of a fast local database.

6. Synchronization services provided you use LiveCycle. Synchronization is the difficult part of enabling offline support in occasionally connected applications.

7. Rich design and multimedia. This is Flash, so ideal for highly customized UIs, animation, sound and video. Adobe is proving the point by creating a media player built with AIR. Existing Flash developers can easily use their skills to build AIR applications.

8. Great for web vendors who want a desktop presence. For example, one of the demo applications is for buying on eBay. If eBay persuades you to install it, then it is no longer dependent on you firing up a web browser and navigating to its site. It is also a good way to disintermediate Google.

9. Declarative programming via FLEX. Declarative programming is the best way to code a GUI and consume components.

10. ActionScript 3.0 combines the flexibility of JavaScript with grown-up object orientation. Option for dynamic or strict typing according to developer preference.

So is AIR your next development platform? Maybe, but there are some downsides:

1. Limited extensibility. AIR apps have file access, clipboard access, support multiple windows, support drag and drop, and can trigger notifications (â€toastâ€ in Windows). If you app needs to interact with the desktop in other ways, the chances are that AIR is not suitable. For example, thereâ€™s no access to COM automation, and no way to execute external applications. The reason is to maintain cross-platform compatibility. Thatâ€™s a worthy goal, but it would be good to have a way out of the sandbox. Unlike Java or .NET, you cannot extend AIR with custom native code libraries. Nor can you call operating system APIs.

2. Database access limited to SQLite or web services.

3. Enterprises need to roll out applications over the network in a controlled manner. AIR has no specific support for enterprise deployment. On Windows, AIR does not use the Windows Installer service. Either Adobe or 3rd parties will need to create deployment wrappers to overcome this.

4. Proprietary technology. AIR applications depend on Adobeâ€™s runtime.

5. No threading support. Architect Kevin Lynch says this is a strong candidate for a future release.

6. No model for commercial components. It is not clear to me how a component vendor could sell an AIR component while protecting it from unlicensed deployment. This may limit the availability of 3rd party components, with a corresponding impact on productivity.

7. Schizophrenic development model. AIR supports either Flex development, or HTML applications which run in WebKit. The ugly side of this flexibility is that there are two SDKs, even two JavaScript virtual machines with different capabilities and characteristics. While it is nice to have a way to render HTML, I am not convinced that the web application model is worth it, given the complications it causes. After all, web applications run perfectly well in the browser.

8. Security concerns. AIR is close to the worst of both worlds, being tightly sandboxed from a developer perspective, but not particularly safe from the userâ€™s perspective. Adobe says it will allow unsigned applications, which I think is a mistake.* AIR has the same access to the file system as the user, which in the case of users running on Windows XP with full admin rights is very extensive. Example bad scenarios would include downloading malware and placing it your startup folder, or searching your file system for bank details and uploading them to some internet location. That said, Adobe says there will be more security features, so conclusions are premature.

9. Synchronization service depends on LiveCycle, the server-side piece which runs on J2E application servers. This is one of the ways Adobe makes money out of AIR, with the other obvious one being design and development tools. A consequence of point 4 above.

10. Lack of UI standards may lead to annoying inconsistencies between AIR applications. We are used to this on the Web; now it is coming to the desktop as well.

*I was told that application signing is not required, but Daniel Dura comments below that this is not the case; however he says self-signed applications will be allowed. Perhaps this is one of the things under discussion. Personally I think the default should be to require applications signed by a trusted certificate, but to provide a way for developers to switch this off.

More at the Guardian