Adobe Air for Ajax Developers review
I have been playing recently quite often with the Adobe Air SDK for Ajax developers. For more than 10 years my focus has been mainly the Java Platform and I did not have to use anything else so far. Don’t misunderstand me, I won’t probably use much the Air in my job activities. My interest for it comes from the involvement in the Spaz project. Spaz is an open source Twitter client written for the Air runtime with the Ajax kit, the story is a very classic one, I was looking for a good Twitter application and after using Twitterific for a few days, finally I switched to Spaz. Spaz answered most of my needs and I was able to easily provide patches to add new features that I was considering as important to me.
The first thing I did was to install the Air SDK for Ajax development. Adobe provides several development runtimes and one of those is based on Web standards: HTML, CSS and Javascript. Once you have downloaded the kit, you need to set the AIR_HOME variable and add to your path the $AIR_HOME/bin expression.
After that you have access to the adl command that allows you to start an Air application. In the case of Spaz, I downloaded the source tree from the SVN and used adl application.xml et voilà! The application just start.
The main advantage of the Ajax runtime is to reduce the entry level for developers. I was already quite familiar with Web and Ajax technologies and Adobe had a great idea to create such a platform. (It helped me to understand better Sun strategy with the heavy promotion of the Java FX platform). Most of the objects you will use are wrappers of Actionscript 3.0 objects, if you look at the documentation you will find for instance that the air.desktop.Icon is an alias for the window.runtime.flash.desktop.Icon. Does the developer cares about that ? I would say yes, because the default wrapper set is partial and does not cover the full platform, therefore sometime you need to use window.runtime.flash.* when you want to access advanced features. It happened to me when I added a feature that display the number of unread message in the dock icon, pretty similar to what Mail.app does.
The platform seems powerful enough. However compared to the Java platform it’s very poor, but the main focus of the platform is to build RIAs and therefore it does not matter much. The integration with the desktop lets you leverage native menus, the dock icon on OS X and the system tray icon on Windows.
The documentation is the weak points of Air. The online API documentation is similar to Javadocs, so you will feel comfortable with it. The main issue comes from the main documentation that does not cover everything. The documentation for the embedded local SQL database is just minimal. When I developed the badge feature for the dock icon, I felt it was possible to leverage the powerful vector capabilities of Air to create nice shapes and indeed I was able to achieve it but as the cost of looking at the Actionscript 3.0 documentation which in my opinion is an issue (well even the Actionscript documentation was not enough) and I was left by myself.
Finally I find the platform powerful and simple, the main issue being the documentation. If you have good Web and Ajax skills you can leverage them to build quickly an application. The main advantage over traditional Ajax application is that you won’t be annoyed when doing cross domain Ajax, won’t have to deal with browser quirks and will create more powerful RIAs. If your Web and Ajax skills are poor, you should consider twice using that platform, but the learning cost in time and resource is not lost as you can reuse your knowledge for building classic Ajax application.
blog comments powered by Disqus