A Critical Evaluation of Abobe AIR
The Adobe Integrated Runtime (AIR) is a cross platform runtime that encapsulates existing web technologies. AIR allows web developers to create desktop applications without the need to learn new skills. This encapsulation allows for easier development and a wider range of skill sets. However it does overcomplicate certain aspects of development; it could be regarded as a double-edged sword. This critical evaluation was written for a University module geared towards the evaluation and usage of 3rd party APIs.
AIR stands for Adobe Integrated Runtime; its goal is to allow developers to create Rich Internet applications. Adobe are hoping to encourage developers to create applications that will blur the boundaries between the Internet and the Desktop computer. Websites in general do not use a GUI style that is similar to the users Operating System; consequently navigating between websites can break the flow of using a computer. AIR can package a website’s functionality into an application that will install and integrate well into multiple platforms .
Overview of Adobe Air
Adobe AIR is a reaction to the increasing growth in web-based applications over the past 5 years. This has been fuelled by the increasing ease of web application creation, and the growth of the Internet as a communication medium. In 2002 Macromedia coined the term “Rich Internet Application” to describe a new type of web application that would provide a better, more desktop like, user experience .
Fig1. The Adobe AIR Application Stack 
While AIR has support for HTML/JSP and Flash individually, you can see from the application stack (fig. 1) the integration is far more intelligent. As is true in normal web development; AIR HTML content is able to load and display flash content. Any Flash based AIR content is also able to load and render HTML pages. This adds to the developer freedom by allowing them to select the best option for the task in hand. AIR also has excellent support for Adobe’s own Portable Document Format (PDF) that has become the de facto standard for sharing documents on the web.
Notable Aspects of Air
Cross Platform Compatibility
AIR has been built upon existing web standards, this has enabled Adobe to create AIR as a fully cross platform runtime. I believe that it is one of AIRs greatest strengths. Not only are developers given an extremely large amount of freedom in developing AIR applications, they are also given the option to develop on there preferred platform. The AIR SDK, and runtime, will install and function correctly on Microsoft Windows, Mac OS X and Linux (Since AIR1.0). Due to Adobes market position and investment into AIR, there are now a number of cross platform IDEs that can create AIR applications. These include Adobes own Flash CS4 and Flex Builder along with 3^rd^ party software such as Aptana. It is also possible for a developer to write an AIR application in a text editor. It can then be compiled and packaged using the tools that are supplied with the SDK.
AIR has created a development culture whereby a developer can write an application using Notepad on a Windows machine, and deploy it to Mac OS and Linux with identical functionality. In the past this would have been a very time consuming task, with many different code builds and deployment methods. AIR allows an application to be written once and deployed many times; this reduces development time, reduces defects and increases code quality. In the current economic climate, these sorts of results are extremely beneficial as they greatly reduce development costs. It is hardly surprising that large multinational companies such as eBay, FedEx, FOX News, NASDAQ and AOL have embraced AIR .
Due to the nature of web applications, they are locked into the browser window and hence cannot provide the same level of user interaction as a desktop application. This is where AIR has a huge advantage, as it runs on the desktop it can provide the functionality and interfaces that are familiar to the user. These include: Install/Uninstall routines, shortcuts, drag & drop, Clipboard and notification support. Once an AIR application is installed it is just another native app, hence OS can interact with it in exactly the same way as normal .
Web applications generally have a very restrictive security model, enforced by the browser. I/O for files is extremely limited and the network resources that can be accessed are also restricted. AIRs security, however, is much more complex. It is using the same technologies that are secure within a browser but now they are running on a Desktop OS with desktop security .
The main difference between the AIR and traditional applications of web technologies is that AIR has access to local files. This provides a huge opportunity for malicious software. Adobe however took steps in AIRs development to ensure security. Firstly all AIR applications run on top of the Operating Systems normal security layer, there is no way to get around this. This will be persistent through any changes the OS vendor makes to the security layer . Due to the security implications, Adobe has engineered the install process to be very similar. The user will need to download the application, install it and then run it just like a normal desktop application. This may seem superficial but it does provide a level of assurance to the end user that he/she is installing a fully-fledged desktop application rather than just a web application.
The final notable area of security that I wish to mention is Digital Signatures. Each and every AIR application has to be signed with a digital certificate when it is packaged into an installable entity. This certificate mechanism is designed to indicate who has developed the application, when it was deployed and reference a security body that can verify the identity of the developer. These certificates are encrypted to a default level of 1024bit RSA and can only be used at deployment time by the developer via a key pair. The public key is embedded within the certificate, the private key is known only to the developer . The only grey area of the digital certificates system is that developers can create their own certificates to sign their applications. This of course does not provide any means of verifying their identity and the applications security. Hence it is ill advisable to put an AIR application into the public domain with a self signed certificate. Adobe has teamed up with Thawte (part of Verisign) and others to provide a service that will allow developers to purchase fully verifiable certificates to sign their applications. This cost may not seem justified initially however the AIR installation process is very damning of self-signed applications. See Figs 2 & 3 for examples.
Fig.2 A self-signed installer window
Fig.3 A signed installer window
As you can see the status of the security certificate is clearly visible from the installer window. This is very important; as it is the first thing the user will see upon running the application installer. The red warning icons on the non-signed window will be effective at deterring unsure users from installing the application.
Chosen Air APIs
To investigate all of the APIs would require more than one prototype application and a lot more time than has been allowed for this project. AIRs collection of APIs provide a myriad of functionality from native windowing and file I/O to application updating. I have instead chosen to look at a subset that I believe best demonstrate the advantages (and disadvantages) of AIR.
Embedded SQLite Database
While AIR does have the ability to access a lot of different file types using the file I/O APIs, perhaps the most interesting is the inclusion of an embedded database engine. The database engine in AIR is SQLite; a public domain software library that implements a self-contained, zero configuration and serverless database engine. It is used in several other high profile products such as DropBox, Firefox, Safari and Apple Mail .
As SQLite is serverless is reads and writes directly to ordinary local files; actually a bespoke file format that is cross platform and cross-architecture (32/64bit). What makes SQLite such a good choice for AIR is that the library itself only takes up 300Kb of disk space when compiled and runs very quickly. Perhaps the best aspect of SQLite for developers is that the AIR API provides a simple method of creating database connections and passing SQL strings to retrieve/modify data. I have chosen to investigate the SQLite functionality of Adobe AIR, as it is not something that I have come across in previous projects.
While the SQLite database API can handle the bulk of I/O required for my application, some portions of the general file access API will also be used. I will be using the AIR file access APIs to locate the database file on the users machine and use that file to open an SQLite connection. The API has a number of built in functions that can load files from the applications install directory, the users home directory, documents directory or any arbitrary folder path.
XML (Extensible Markup Language) is becoming increasingly widespread in modern web applications. The HTML like structure of an XML file allows accessing and using the data to be done very easily. AIR uses an abstraction of the URLLoader class from Adobe Flash . In reality the URLoader class can be used for many other tasks aside from XML parsing. It can be used to download other data types from a URL, including text and binary data. In other circumstances it can be used to create a data packet (text, XML etc) and then upload it to a given URL.
Another feature of Adobe AIR that improves the desktop integration is handling of native menus. Web applications will generally only use standard controls that are confined to the browser window, so they will not be able to use native OS menus. AIR allows a developer to create a set of menus for his/her application that will use the menu system of the client’s operating system .
It is very important to allow for several operating systems when developing a menu system. This is due to the fact that Mac OS uses a different menu layout to Windows and Linux. On Windows and Linux, each window of an application has its own menu strip, but on Mac OS all windows share the common menus stored on the finder bar, see figs 4 & 5. AIRs menu API provides functions to handle these; nativeWindow.menu for Windows and Linux, Mac OS is handled by nativeApplication.menu.
Fig. 4. An Example of window menus on Linux
Fig. 5. An example of the common finder menu strip on Mac OS
As mentioned earlier in this report, all AIR applications need to be signed with a digital certificate when they are packaged for deployment. I will be using a self-signed certificate, generated by the AIR SDK, to demonstrate this system. Of course this will produce the warning on the installation screen but it is not financially feasible to purchase a certificate just for this small project
As AIR is built upon many technologies, I am slightly concerned that some of the simplicity of web development will be lost. HTML/JSP development is very different from developing an application using ActionScript, but AIR is attempting to merge the two. It becomes immediately apparent that the APIs themselves will need to be very well written to consider all aspects of flash and HTML/JSP if they are to work correctly. All of the subtle nuances of the two languages will need to be accounted for or the APIs will not work correctly. As a result of this I believe that certain tasks will require a little more programming that would seem necessary at first.
Due to the fact that Adobe have taken web technologies and applied them to a completely different security model, I think that issues may arise. Normally a web application does not have access to local files and networking resources but AIR applications do.
Adobes solution to this was to implement sandbox layers to an application. My concern is that it may not be immediately obvious, during the development, what is restricted and what isn’t. As a result several hours may be spent trying to bug fix something that will never work due to the security layers. Hence more time will be spent developing a work around solution to these problems. While this is extremely good for the end user, making his/her computing experience safer, it may in fact increase the development time and cost.
Declarative vs Imperative
Declarative programming languages are languages that are only concerned with the logic of an application or the content of an application window. HTML can be defined as a declarative programming language as it is only concerned with describing the content of a web page (or AIR window in this case) and not with how the content is generated. Other examples of declarative languages are Prolog or Haskell . Imperative programming languages however are concerned with the generation of content in a page or window. The language needs to explicitly specify the manipulation of states in the computer system .
Design of Prototype
To fully evaluate a product as complex and far ranging as AIR a comprehensive prototype is needed. I have chosen to develop an RSS feed manager and reader, using HTML & JSP. RSS is a family of XML based web formats, which are used as “latest story/item” feeds for a variety of websites. News organisations often use them to provide a quick means of showing headlines without the need for users to trawl through pages of articles.
To demonstrate the SQLite integration and the file I/O side of Adobe AIR my prototype will allow users to manage their RSS feeds. The prototype will be including a simple CRUD (Create, Read, Update and Delete) system that will enable simple and quick management of feeds. To add a feed, all the user will need to do is open the “New Feed” window, enter the feed name and the URL of the RSS feed and click Add. The details of the new feed will then be added into that database and it will be viewable on the main news screen. An “Edit feeds” window will handle editing and deleting feeds. This window will display a list of all the feeds currently in the database. The user can then click on a feed, which will then display the details of it in a new window. The feed can then be edited, or deleted, which will update the database with the changes.
The final aspect of the prototype demonstrates AIRs ability to handle the native menu systems of Windows, Linux and Mac OS X. The prototype will be able to detect which operating system the application is currently running on and then create the appropriate windows. The menus will allow the user to create a new feed, edit existing feeds and view the news. On Windows and Linux only the initial window of the application will have menus attached to it. However on Mac OS the menus will be on the finder bar and will be usable at all stages of the applications usage.
Justification of Prototype
I believe that my prototype design demonstrates Adobe AIR effectively through my choice of APIs. Obviously it would not have been possible to show all of the APIs that AIR contains. But I feel that the chosen APIs are ones that are commonly used in the creation of Rich Internet Applications hence they are important ones to evaluate.
Summary of Prototype Development
The process of developing the prototype, now called AiRss, was remarkably easy. The thing that shocked me most about developing using AIR was how little learning I had to undergo before I could dive straight in and create large applications.
The only real preparation that I had to do before starting was
installing the SDK and choosing what IDE to use for the development. The
SDK was extremely easy to install, just a simple zip file to download
from Adobe and then the libraries are immediately useable. They are
simply referenced using a HTML
<script\> tag. I started off by using
the SDK in its raw state and writing some applications using TextEdit in
Mac OS. Again this was amazingly simple to do, once the libraries were
included it was easy to do a lot of very complex things. The only
problem being that TextEdit does not have any code prediction or support
for AIR. At this stage I opted to install the Aptana web development
IDE, which has excellent support for AIR. It is based upon the Eclipse
IDE framework and has a built in AIR SDK hence the code prediction and
support is excellent.
The first portion of the development I carried out was the CRUD management of RSS feeds. I opted to do this first, as I believe that it was the most complex area and should be got out of the way first. Creating the forms was relatively straightforward; creating the database connection took a little more time but was very intuitive. The management of the RSS feeds was achieved using a very similar method to the addition of new feeds. The form design was very similar, the only difference being that the input fields were populated with database data rather then being blank. Once this had been done, the actual displaying of the RSS feed items was very simple. The AIR APIs handled the work of connecting to the database, downloading the XML and parsing the data very well.
Notably Good Areas
Secondly I was impressed at the speed and correctness of AIRS WebKite implementation. Webkit is widely regarded as one of the best rendering engines in use today. For a web application a certain amount of delay in loading windows is generally accepted, but with a desktop application it is not. Hence it is paramount that AIR windows load as quickly as possible.
Finally AIR provides another library that is invaluable for developers, it is called the AIR Introspector. It provides an excellent debugging interface that is launched via the F12 button. It allows all of the source code for the current window to be viewed, split down into languages and functions. It also provides a console that allows specific functions to be run which will help a developer in tracking down a bug.
The second problem that I ran into was concerned with the security aspects of AIR. Originally I was storing the SQLite database file within the application install directory. This seemed to work on my Mac but once I had deployed the application onto Windows and Linux it stopped working. I discovered that it was working on my Mac in debug mode but not when it was installed as a real application. Upon investigation and reading of the documentation I discovered that this was due to a security restriction. All files stored within the applications installed directory are consequently run with application security privileges. This meant that reading from the database would work fine but the application could not write data back. The workaround for this was to store the database file within the users documents directory; AIR provides an API call to do this easily. The only caveat of this is that when the application is first run it needs to check for the existence of a database in the documents folder. If the file does not exist, a template database is copied from the application directory to the documents folder.
My overall opinion of Adobe AIR is very positive. Developing with it proved to be an extremely smooth and rewarding process. Anyone with reasonable web skills will feel immediately at home with AIR. Adobe has taken a lot of steps to ensure that the move from the web to the desktop is not a difficult one.
Adobe AIR has many advantages that I have uncovered during this project in development and research phases. I feel the main advantage is simplicity. The intelligent way in which AIR has been created, allows the APIs to be accessed in a very easy way which facilities efficient development. The way in which the APIs are implemented also allow for good code reductions in areas that would be quite cumbersome in some web technologies.
I am also massively impressed with the high level of security that Adobe has implemented with AIR. They have realised that taking web technologies out of their normal, highly restrictive, security model could create a vast potential for misuse. Not only have they ensured that all AIR applications run on top of the Operating Systems own native security, they have also restricted certain portions of the underlying web technologies. This combined with the expansive digital certificates system ensures that the user of an AIR application can be safe.
With the small section of APIs than I investigated I ran into some issues that I was not entirely happy with. The conflict between declarative and imperative languages caused some portions of code to be longer than would be expected. The security model caused some unexpected behaviour that I had to create workarounds for. I do not want to give off the notion that I have become dissatisfied with AIR because of these problems. I believe that I could have avoided the security issues if I had read the documentation in more detail before starting the development process. Also the increased code complexity created in some areas of an AIR application are far outweighed by the savings created by the efficiency of the APIs themselves. The fact that Adobe have managed to join this many popular web technologies into one working package is nothing short of astounding.
Overall AIR is something that I would recommend all web developers to try out. If not to create full applications but just to see what other avenues their skills can be used in. Yes there are still a few problems but AIR is still a young platform and I have no doubt that Adobe will make every endeavour to make it better and better.
 Adobe Inc (2009) Browser vs. Desktop, http://www.adobe.com/products/air/comparison/ - Date Accessed 15/3/10
 Adobe Inc (2009) Adobe AIR Flex Data Sheet, http://wwwimages.adobe.com/www.adobe.com/products/air/pdfs/air_flex_datasheet.pdf - Date accessed 15/3/10
 Adobe Inc (2009) Adobe AIR, http://www.adobe.com/products/air/ - Date Accessed 15/3/10
 Lucas Adamski (2008) Introducing the Adobe AIR security model http://www.adobe.com/devnet/air/articles/introduction_to_air_security.html - Date Accessed 10/3/10
 Oliver Goldman (2008) Code Signing in Adobe AIR http://www.drdobbs.com/web-development/210004209 - Date accessed 16/3/10
 SQLite Developers (2010) About SQLite http://www.sqlite.org./about.html - Date accessed 16/3/10
 Adobe Inc (2010) Working with External data (Adobe AIR 1.5 Documentation)
 Sean Monahan (2009) Creating Application menus in Mac OS X with Adobe AIR, http://bkwld.com/blog/2009/11/creating-application-menus-in-mac-osx-with-adobe-air/) – Date accessed 16/3/10
 Free Online Dictionary of Computing (2010) Declarative Language Definition, http://foldoc.org/declarative+language - Date accessed 17/3/10
 Free Online Dictionary of Computing (2010) Imperative Language Definition, http://foldoc.org/imperative+languages) - Date accessed 17/3/10