25 Nov, 2008
Limitations of Adobe AIR
Posted by Bhavin Turakhia
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.
That’s a good summary of why AIR is, in its current form, just a toy and not meant for serious applications.
To address these shortcomings the MCrux project has been started:
http://www.mcrux.com/
http://code.google.com/p/mcrux/
It will become a fully extensible plug-in based application platform using Javascript/HTML (WebKit) to allow a rich user interface and rapid development, combined with APIs from DLLs (C++, VB, etc) for all lower level backend power.
Pretty correctly pointed out Bhavin, These are real limitations present in the whole platform, and IMO I don’t think Adobe will do much in a large number of these areas (especially in areas of support for building services / daemons / protocol servers) as I don’t think they intend to go head-on with MS or any hardcore low level application development platform. That however does not necessarily mean that AIR will not have wide scale adoption and use.
@cbas - I completely disagree with you about the toy aspect of things. Its not the hardcore-ness of the development platform and the total capabilities of what the platform can do …. ITS WHAT YOU MAKE OF IT - come on now, VB script was dismissed as a toy nearly a decade back, and still it powers Pandion - probably still the best XMPP client out there (who else would know that better :)) . Now compare that to the Spark client from open fire. Made with Java - the platform that’s supposed to be capable of everything (apart from managing its memory footprint apparently) IMO - Spark is nearly un-usable.
So the perspective of choice completely depends on what you want to make. Bhavin, incase you want to make something that requires you to easily call dlls, have an accompanying service/daemon, you need low level system power etc, its best to keep off the AIR strategy completely. I dont foresee them going there - But then i am just speculating
Ahh yes! I’d like to add one more point to your list. AIR DOES NOT DO GLOBAL HOTKEYS! Now i can understand that Air cant be used to make a daemon, but no global hotkey binding for a desktop app ?? Thats got to be the freakiest shortcoming of a desktop platform!
Cheers
Adobe’s strength is not in its technology. Look at number of users who have Adobe Reader on their desktop. It is almost ubiquitous. I suspect sun does not enjoy so much wide spread adoption for its java. Now Adobe is trying to push Adobe Air along with its next version of Adobe reader. Even if the technology sucks some people may live with it as a compromise for wider adoption.
Yesterday Sun released their Java FX which is one more contender in this space for building RIA. Only time will tell who is the winner.
I like the idea of it being a desktop type widget. I could see it being a little app for your clients to get bits and pieces of information from your normal Web app/Protal without having to open the browser. I find more users do not want to open the browser, login, go to this page or that page. They want information they select then when it becomes interesting or important then they go to the Web App/Portal. Does it need to be more than this? Should the next steps be adding better database support? Not sure. @India PR is correct that “time will tell” .
AIR mandates that following service packs be there. Windows Vista SP1, Windows XP Tablet PC Edition SP2 and SP3, Windows XP SP2 and SP3, Windows 2000 SP4.
The customer’s laptop/PC should have the requisite SP installed as a prerequisite for installing my application.
Qt + Good SVG graphics can easily give AIR apps a run for their money.
Dear Bhavin,
Please send me an email,
I want to talk to you.
Thanks.
I don’t see those as limitations, those are by design. The idea was to have a cross-platform runtime which allows developers to use existing skills (html/css/js/actionscript/flash) to build RIAs for desktops.
Allowing to load DLLs or invoking native or system executables not only brings issues in portability (securly) of entire runtime but also various security issues.
I guess, there is already established trust system and people don’t mind installing AIR (runtime). AIR apps do require an understanding, like any other desktop apps, you install only when you know what you are doing.
-abdul
Bhavin,
I was surprised that nobody here mentioned MDM Zinc 3.0.
When AIR was first propsed by Adobe I thought, “Why are they bothering with this when there is already such a mature product on the market”? Zinc has been out for years and supports quite a lot more than AIR, for me as a game developer one of the biggest pros is the ability to use DLLs (and I hope in future, shared obects for Linux and dylibs for OSX).
Seriously: AIR is a joke compared to Zinc. I’ve written an application in each so I have some grounds for comparison. Zinc costs a bit of money ($350 US) but I would say it’s well worth looking into as it simply offers a lot more.
The lack of multi-threading, at the top of your list is, I suspect, at the top of everyone’s list. But beyond threading the other ’shortcomings’ you list don’t really belong on a list of complaints. A cross-platform environment like AIR / Flash should tread lightly or not at all on native APIs, DLLs, etc.