25 Nov, 2008
Limitations of Adobe AIR
Posted by Bhavin Turakhia | (24) Comments
Most people tend to compare AIR and WPF/.NET. The predominant assumption is that AIR is to WPF as Flex is to Silverlight. AIR is touted as a cross platform desktop application development environment. This assertion holds true for basic widget-type desktop applications with limited functionality. The model begins to fall apart when you begin moving out of basic widgety apps into the realm of true rich and complex desktop applications. Some of the most fundamental shortcomings that come to mind are -
- AIR does not support multi-threading
- AIR does not allow making native calls to the underlying operating system APIs
- AIR does not permit loading native libraries (eg DLLs / C libraries etc)
- Limited Database support (no drivers for diverse databases)
- Limited Networking support (Raw network socket manipulation not available)
- Installer cannot be extended to install ancillary executables or other processes
- Limited to no support for building services / daemons / protocol servers
- Relatively strict sandbox
This is a short list of hurdles that I have come across. There are certainly many more limitations over and above these. AIR is essentially more like an extension of a chromeless browser, meant for running a web application within a desktop environment. It cannot be compared to a powerful desktop programming language like .NET (with WPF). Infact even XUL has better support for writing rich Desktop applications than AIR.
On the flip side I hear many good things about AIR in terms of ease of development. AIR apps can be developed in significantly lower timeframes than in most other desktop development environments. AIR also enables sharing of codebase between a web app and a desktop app.
Hopefully Adobe will catch-up on the missing elements soon, so that AIR becomes a strong enough contender to the current limited number of existing desktop development environments.
