Archive for the ‘Air’ Category

The footprint of the Air Ajax runtime

Thursday, August 21st, 2008

When I started to use Spaz, I naturally twitted about it and of one my friends tried it. He recognized that the application was better than Twitterific but did not adopt Spaz because of the OS resources consumed by the application. I know a bit the heart of Spaz as I developped a few of its features, I know that it does not waste resources and I concluded that perhaps the runtime could be the cause of this overhead.

This morning, I downloaded one of the simplest applications written in Air Ajax, the classic Hello World application. I simply executed the application adl -nodebug application.xml and used the Activity Monitor utility provided by Apple to measure the memory and CPU footprint. The question is simple: what is the overhead of an application that nearly does nothing and have nearly zero state ? Note that I use the -nodebug switch which optimizes the runtime, thanks to Ed Finkler that gave me the hint. It helps to reduce the CPU used by the application by a factor of 2. The first version of this entry did not take it in account.

Disclaimer: this test is very subjective and if someone else performs the same test, he will likely find a different result.

The answer is pretty big for me. My machine is a MacBook Pro 2ghz with 2 gigs of RAM (I can’t have more because it’s one of the early models). The application uses constantly around 2% of CPU and 20 megs

It is way too much for desktops. I wondered then how does it scale if I run 10 times the same application ? Perhaps that Air has a smart runtime that can collocate resources ?

Ten Hello World Footprint

Ten Hello World Footprint

According to my results, running 10 Hello World application consumes around 200 megs of RAM and around 20% of my CPU. Clearly I see a problem here, how can the end user really uses several Air applications at the same time without consuming too much OS resources ?

That reminds me the story of the Java virtual machine. Back in 2000, the early versions of the Java virtual machine were slow and gradually they improved the performance of their virtual machine. If I remember correctly the JDK 1.4 was the first release to provide decent CPU performances and then each major release had seen decent performance boosts. BTW: Sun’s VM also uses lot of memory but the CPU footprint is nearly zero. Reducing memory overhead is not achieved yet, I know they have plans to collocate if you execute several virtual machine though, I am not an expert.

I hope that Air will follow the same path and that Adobe will invest in the optimisation of the runtime. In my opinion it is a key factor to increase the adoption of the platform.

Adobe Air for Ajax Developers review

Monday, August 18th, 2008

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.