Adobe Integrated Runtime – “AIR FORCE” part 1
12 June , 2007Posted by on
In this article I want to go a bit more in depth about the Adobe Integrated Runtime (formally known as Apollo), in short AIR (sounds like error 😉 )
This article will go ‘On Air’ in 2 parts
PART 1 :
1. AIR Introduction and overview
2. AIR Security
3. AIR windowing API
4. AIR filesystem API
5. AIR SQLite
6. Examples !
Let’s start …
1. AIR Introduction and overview
Adobe Integrated Runtime (AIR) is a cross operating runtime that makes it possible to deploy RIAs to the desktop. The runtime is installed on the client machine and runs the AIR applications. The runtime can be downloaded by the end-user on the adobe website when prompted or can also be packed in the installer package. The cool thing is that end-users can interact with AIR applications like they are doing with native desktop applications. Also to develop these AIR applications developers can use their existing skills set to deploy to the desktop. Actually it is all a consistent platform.
If we talk about benefits; there are a few very clear:
- complete control over the application
- target the runtime, not a specific OS
- rapid development with existing technologies
- no complex low level OS specific API’s.
There is an API specific to AIR and also an Actionscript API which allows you to extend existing applications to the desktop.
If we talk about applications for the desktop, then security risks arise because you have access to the operating system. But with AIR you have less restrictions then when running into a browser. You have the installer security warnings during the installation. There is a security notice, publisher information and system access permissions. So you are informed and can make a decision before installation.
Each application has an AIR sandbox (local files for use by the application). You can check the type of the sandbox by using the sandboxType property of the security class. The File type and the relation to the application determine the type (eg: local with networking). There are also a few privileged resources:
- SWF files in the application can crossscript any SWF in the application (eg. by using localConnection).
- SWF files outside the application are restricted
- There are no cross domain policy files
- You can read and write to local resourses.
- The Flash player settings do not apply
When developing an AIR application you can also build in several extra security checks. Sure be aware of the capabilities AIR has. Be cautious with networked data or the file system. Remember these words as a best practice when working with AIR applications.
3. AIR Windowing API
AIR has a cross platform windowing API; this means that every application will looks like a normal desktop application. The applications are very skinnable to your own design or shape. There are actually two types of windows:
The first window is created for you by AIR which will show the rootcontent of your application. The rootcontent element tells the application what to load and also defines what chrome to use. You have the System Chrome and No Chrome. It sets also the transparancy, the visibility, width and height.
The windowing API uses an event based model. This means that events are dispatched and these will be picked up by listeners who are listening for events of interest.
This is the end of the first part of the article. In the second part of the article there will also be some examples on the Windowing API (multiple windows).
If you have suggestions or comments, let me know by leaving a comment…