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.

Introduction

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 [1].

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 [2].

At the very core of Adobe AIR is a lightened version of the WebKit rendering engine. As AIR encapsulates so many web technologies, a rendering engine that handles them all very well on multiple platforms was a necessity. There are 2 core technologies at work within Adobe AIR, although not all of them have to be used in an application. The first core technology is HTML & JSP; the rendering engine has full support for HTML, XHTML, CSS, JSP and the Document Object Model.  This means that fully fledged AIR applications can be developed using HTML and JavaScript, this is a huge bonus for web developers who may be unwilling to delve into the realms of Flash and ActionScript. However those who are already familiar with Adobe Flash will feel at home with AIR. AIR is built upon Flash Player 9 so all of the existing flash APIs are intact and will be instantly accessible. Some advantages that Flash brings to AIR include a full networking stack, vector based drawing and excellent multimedia support for common image, audio and video formats. As AIR has been built upon the newer ActionScript 3 standard, it is possible for developers to use either Adobe Flex Builder or the standard Flash builder to develop AIR applications. This amount of developer freedom is unprecedented and is indicative of AIRs popularity. [2]

Fig1. The Adobe AIR Application Stack [3]

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 [4].

Desktop Integration

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 [2].

Security

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 [2].

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 [2]. 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.

Within any AIR application there are a set of APIs that provide the access to local files and network resources, that a normal web application would not have access to. To just let all code have access to these APIs would be irresponsible, hence Adobe has implemented “sandboxes” to segregate access. The “application sandbox” can use these APIs but some “dangerous” code patterns and functions are restricted. For example dynamic loading of remote content is not allowed, only content loaded from the application directory. An example of a restricted function is the JavaScript eval() function. This function is often used to generate code from templates and/or a remote domain, it is obvious the potential this has for misuse [5]. Any content that is not loaded into the application sandbox will not have access to the file and network I/O APIs. This content will behave in exactly the same way as it would in a browser, as per the specification for each technology (HTML/Flash).

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 [6]. 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 [7].

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.

File Access

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 Parsing

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 [8]. 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.

Native Menus

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 [9].

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

Digital Certificates

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

Possible Problems

Encapsulation

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.

Security

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 [10]. 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 [11].

My concern is that as AIR is using web technologies it will need to mix the two programming paradigms. The content of the application windows themselves will need to be defined using a Declarative language, either HTML or MXML in the case of Flex Builder. But the AIR APIs will of course need to manipulate data and create content to display in the application windows. Hence the APIs themselves are written in imperative languages (either JavaScript or ActionScript) and must be referenced from a similar language. So I believe that an increased amount of code will be required for simple tasks, for example opening a new window in the application. The new window will need a HTML or MXML page to describe the layout and content but these pages will not be able to define how the content is gathered, the options for the window (size, resizable, hidden etc). These options will need to be defined in a separate place using an imperative language.

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.

The prototype will be able to download the latest XML data from an RSS feed, parse it into readable items (title, story, URL) that the user can then view. Of course just viewing one feed would not fully demonstrate the API; hence the user can view multiple feeds at the same time. All of the latest items from each feed will appear on the “Read all About It” window of the application. As a further demonstration of the API flexibility the user will be able to select which feeds he/she wishes to view and how many news items to display for each feed. Finally the user will be able to click on the “More…” link on each news item, then the full story will open in his/her default web browser. The URLoader API in Adobe AIR will handle the actual downloading of the RSS feeds. But it should be noted that once the XML is parsed, it will be displayed on the application window using normal JavaScript DOM methods. Cascading Style Sheets have also been used to ensure that the feeds display correctly in the window.

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.

My choice to develop the application using HTML & JSP was motivated by the fact that I prefer it to using ActionScript. I have had experience in developing web applications in the past so my skills should be easily transferrable to AIR. This is exactly what Adobe was planning for when AIR was being developed: to allow web programmers to develop for the desktop without learning new skills. The use of JSP allows me to carry out the rest of the processing that AIR cannot handle. By this I mean that the display and access of HTML controls will be handled using standard JavaScript techniques, via the Document Object Model. In fact I have opted to use the open source library JQuery, as it allows complex DOM manipulation to be carried out quickly and easily. This is still within the scope of AIR, in my opinion, as it allowing DOM to be used in a desktop context. The only other external technology that I have implemented is Cascading Style Sheets. I have used CSS to improve the interface of the application and to ensure that the RSS items display correctly.

Summary of Prototype Development

Development Process

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

There were several areas of AIR that really impressed me during the development of the prototype. First of all the simplicity of the APIs and how to use them was excellent. To use the APIs within JavaScript just one include file has to be added: AirAliases.js. This file is used to reference all of the API calls that AIR provides as well as reducing the amount of code needed. For example to open a file for reading/updating, the full API call is window.runtime.flash.filesystem.File. AIR reduces this down to air.File; which is obviously a lot easier to manage from a development point of view. This reduction in code is apparent through a lot of AIR development. For example opening a connection to a database took remarkably little code:  7 lines of code, including full try/catch error handling, see fig 6.

Fig. 6. Connecting to a Database using Air in Javascript

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.

Problems Encountered

As with any software development process I did encounter some problems while creating the prototype. The first problem that I ran into confirmed some of my suspicions about AIR. The section of this report on Declarative vs Imperative languages did become relevant during the development. The creation of a new window as a particularly good example of this, in that the content of AIR window would be defined in a HTML page but the HTML would not be able to handle whether or not the window needed to be hidden, resizable or minimisable etc. The options and the creation of window had to be written in a separate JavaScript file. This then had to load the HTML content into the newly created window. In reality this is not a massively important problem, I just feel that it is a more cumbersome that it needs to be. On the other hand it is slightly unavoidable in the context of AIR, as it needs to use the standard coding styles of web languages.

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.

Conclusions

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.

References

[1] Adobe Inc (2009) Browser vs. Desktop, http://www.adobe.com/products/air/comparison/ - Date Accessed 15/3/10

[2] Mike Chambers, Daniel Dura, Dragos Georgita, and Kevin Hoyt (2008) Adobe AIR for JavaScript Developers -

[3] 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

[4] Adobe Inc (2009) Adobe AIR, http://www.adobe.com/products/air/ - Date Accessed 15/3/10

[5] 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

[6] Oliver Goldman (2008) Code Signing in Adobe AIR http://www.drdobbs.com/web-development/210004209 - Date accessed 16/3/10

[7] SQLite Developers (2010) About SQLite http://www.sqlite.org./about.html - Date accessed 16/3/10

[8] Adobe Inc (2010) Working with External data (Adobe AIR 1.5 Documentation)

[9] 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

[10] Free Online Dictionary of Computing (2010) Declarative Language Definition, http://foldoc.org/declarative+language - Date accessed 17/3/10

[11] Free Online Dictionary of Computing (2010) Imperative Language Definition, http://foldoc.org/imperative+languages) - Date accessed 17/3/10