You can read more about it here, and download it here.

Two of the most requested features for Adobe AIR have been the ability to launch native executables from an AIR application, and the ability to integrate native libraries into an AIR application. Unfortunately, neither feature will be included in Adobe AIR 1.0.

However, this does not mean that you cannot build an AIR application that has closer / tighter integration with the underlying operating system. This lower level of integration is possible, but it requires some work on your part. I have put together a proof of concept project, which shows how to integrate Adobe AIR applications with c# / .NET code on any operating system that Adobe AIR currently runs on (Mac and Windows). The project is called CommandProxy. It provides a communication proxy between an AIR application and the underlying operating system and could theoretically work with other web based desktop runtimes (such as Mozilla Prism).

Update : I have posted some additional thoughts on this proof of concept here.

Note, this project is in no way supported by Adobe. This is a proof of concept project that I put together to help developers understand one possible way to extend AIR functionality beyond that that is provided by the runtime.

The general concept behind the project is similar to the now defunct Artemis project (which is Java based). The AIR application communicates with the CommandProxy process to communicate and integrate with the underlying operating system. Currently the command proxy supports launching processes (and getting the output from the processes) as well as taking a screenshot of the user’s current screen. However, the framework is built in such a manner that it is possible to add new functionality to the proxy.

Here is an overview of the life-cycle of an AIR application using the command proxy.

1. Command Proxy process is launched by the user. The shortcut for the process passes in the path to the AIR application to launch (or this can be hard coded into the proxy)
2. The Command Proxy process then launches the AIR application, passing in a communication key, as well as the socket port that the AIR application should use to communicate with the proxy.
3. The AIR app may then at some point communicate with the proxy to execute a command. For example, it may tell the proxy to launch a specific process.
4. The proxy executes the specified command.
5. If appropriate, the proxy then returns any command output back to the AIR application.
6. The command / response cycle can occur multiple times during the application life-cycle
7. When the AIR application process is terminated (i.e. the user closes the application), then the proxy process automatically exits.

Currently, the project is meant as a proof of concept, and not as a general use framework. This mainly means that there is not a lot of documentation (although the code is fully commented) and if you want to use it, you are going to have to compile the proxy yourself. If there is interest, then I am willing to expand the project to other contributors.

If you wanted to use something like this in a production level application, then you would need to:

• Compile the CommandProxy
• Compile the AIR application
• Create the AIR file to install the AIR application
• Create a custom installer that first installs the AIR application, and then installs the short cut to the command proxy

Instead of launching the AIR application directly, the user would launch the command proxy process, which would then launch the AIR application.

The project is hosted on Google code, and includes the following:

• Full C# / .NET code, compilable under Visual Studio and Mono. (Screenshots do not work under Mono)
• ActionScript 3 library for communicating with the proxy.
• Some very basic documentation

If you have questions, then post them in the comments and I will try and address them (and maybe create an FAQ on the project page). If there is interest, then I could also create a mail list on Google groups to discuss the project. If you find bugs with the code, then post them on the project’s issues page.

I am also hoping to post some examples of AIR apps that use the proxy. Lee Brimelow built a simple example of an AIR application that takes a screenshot, and then opens it in Photoshop for editing. You can see a demo of that example toward the end of the video posted here (it is about half way through the video).

Update : The code is released under an MIT License.

You can find more information on the CommandProxy project page.

Update : I have posted some additional thoughts on the code here.

I just noticed over on the labs wiki that the Adobe AIR For JavaScript Developers Pocket Guide has been translated to Thai.

You can view the full translation here.

Creative Commons FTW!

If you have been following Adobe AIR during its young lifetime, then you have probably noticed that it has been pretty inconsistent as far as branding goes. It has had a number of logos and graphics associated with it, including the rocket-ship, and the current “AIR” branding.

Part of this was due to the surprisingly complex process of designing and settling on a logo in the technology world. There have been quite a few times during the past year where we felt that we were close to having the final logo, only to then find out that it was just a bit too familiar to some other logo in the computer / internet / tech world.

Well, I am happy to say that we have the final logo. I had the honor of showing it for the first time today, at the Adobe User group meeting in Paris.

I am not going to go into a detailed analysis of what the logo represents, but I do want to point out one of the core concepts behind the logo. Adobe AIR is built on top of three core web technologies (HTML, Flash and PDF), and we wanted the logo to represent this. Thus, each corner of the logo represents one of these core technologies.

We are going to be posting some “Download Adobe AIR” Badges (88 x 33) over the next couple of days in case you want to show your support for AIR. Feel free to build you own (if you do, post them in the comments). Who knows, if there is enough interest, maybe we will have a contest to see who can make the best Adobe AIR badge or desktop wallpaper (post in the comments if you are interested). (I will upload an vector version of the logo shortly).

One last note. Normally, this is the type of information and news that we would post on the main website and not on a weblog. However, we know that the success of Adobe AIR is dependent on developers and the applications and content that they create. As we have learned from Adobe Reader and the Flash Player, content drives adoption. This is why we are posting the logo here first. We wanted the developer community to be the first to see the new logo.

You can find out more information on Adobe AIR on Adobe Labs.

Update : You can download vector versions of the logo here.

One of the cool features of Adobe AIR (especially for Flash developers) is its ability to render full featured HTML within Flash content. The rendering is handled by the WebKit core, and the HTML content can be from both local and remote URLs as well as from a string of HTML text.

HTML rendering within Flash content is handled by the ActionScript HTMLControl class (which is wrapped by the HTML component in Flex). The HTMLControl class is a DisplayObject instance (it directly inherits from Sprite) and thus renders its HTML directly to the display list.

However, it is possible to load HTML content into an HTMLControl instance, without placing it on the display list to be displayed. HTML content is still loaded and executed, and its DOM is exposed to the scripting environment. This means that you can essentially use the HTMLControl to load and parse HTML with the sole purpose of retrieving data from the HTML… i.e. using the HTMLControl you can treat HTML as a data source, as if it was XML.

This is done by leveraging the JavaScript APIs within HTML for manipulating the HTML DOM.

Below is a simple example that loads some HTML, and then uses various JavaScript DOM APIs to extract data and information from the HTML. Note that the HTML is never displayed or rendered to the screen.

index.html

<html>
<head>
	<title>Example HTML Page</title>
</head>
<body>
	<h1>Title 1</h1>
	<p>This is some sample text for title 1</p>

	<p id="foo">This is the foo id</p>
	<p><a href="http://onair.adobe.com">onair</a></p>
	<p><a href="http://www.adobe.com/go/air">Adobe AIR</a></p>

	<ul>
		<li>List Item A</li>
		<li>List Item b</li>
	</ul>

</body>

HTMLParsingExample.mxml

<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" 

	layout="absolute">

	<mx:Script>
		<![CDATA[
			private var html:HTMLControl;
			private function onLoadAndParseClick():void
			{
				html = new HTMLControl();
				html.addEventListener(Event.COMPLETE, onHTMLLoadComplete);
				html.load(new URLRequest("app-resource:/index.html"));
			}

			private function onHTMLLoadComplete(e:Event):void
			{
				//get a reference to the top level html document
				var document:JavaScriptObject = html.window.document;

				/********** find number of links in html page ************/

				//grab all of the links in the document
				var a:JavaScriptObject = document.links;

				//get the length
				var len:int = a.length;

				trace(len + " links in html page.");

				/*********** Find element by ID and get its value ***********/
				var foo:JavaScriptObject = document.getElementById("foo");
				trace(foo.innerText);

				/*********** Use the document DOM parsing API to parse out LI items **********/

				//get all of the UL items
				var lists:JavaScriptObject = document.getElementsByTagName("ul");

				//make sure we found some
				if(lists.length > 0)
				{
					//grab the first one
					var ul:JavaScriptObject = lists[0];

					//get the child nodes
					var childNodes:JavaScriptObject = ul.childNodes;

					var childLen:int = childNodes.length;
					var tempNode:JavaScriptObject;

					//loop through the nodes looking for LI elements
					for(var j:int = 0; j < childLen; j++)
					{
						tempNode = childNodes[j];
						if(String(tempNode.nodeName).toLowerCase() == "li")
						{
							//print the value of the LI element
							trace("LI Found : " + tempNode.innerHTML);
						}
					}						

				}
			}

		]]>
	</mx:Script>

	<mx:Button label="Load and Parse" right="10" bottom="10" click="onLoadAndParseClick()"/>

</mx:WindowedApplication>

One thing to remember is that when working with the JavaScript APIs from within ActionScript, most of the APIs return JavaScriptObject, JavaScriptArray, and JavaScriptFunction instances (and not ActionScript Objects, Arrays and Functions).

You can view the API docs for all of the AIR classes here.

One of the things that you might need to do when building your application is detecting whether your application has run before. This can be useful if you need to initialize settings, or perhaps prompt the user with some information.

Below is a simple example that shows how to detect whether the application has run before. Basically, it checks for the existence of a file. If it doesn’t exist, then the app hasn’t run before, if it does exist, then it means that app has run.

<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication
	xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute"
		creationComplete="onCreationComplete()">

	<mx:Script>
		<![CDATA[
			private const FIRST_RUN_TOKEN_FILE:File =
					File.applicationStorageDirectory.resolvePath("firstrun");

			private function onCreationComplete():void
			{
				if(FIRST_RUN_TOKEN_FILE.exists)
				{
					outputField.text = "This application HAS been run before";
				}
				else
				{
					var fs:FileStream = new FileStream();
						fs.open(FIRST_RUN_TOKEN_FILE, FileMode.WRITE);
						fs.close();

						outputField.text = "This application HAS NOT been run before";
				}
			}

			private function onResetClick():void
			{
				if(FIRST_RUN_TOKEN_FILE.exists)
				{
					FIRST_RUN_TOKEN_FILE.deleteFile();
				}
			}
		]]>
	</mx:Script>
	<mx:Text top="10" left="10" right="10" id="outputField"
					textAlign="center" fontSize="20"/>
	<mx:Button label="Reset First Run Status"
			id="resetButton" click="onResetClick()"
				horizontalCenter="0" width="153" bottom="10"/>

</mx:WindowedApplication>

If you need to know how many times the app has been run, then you could just write a number to the file and then increment it every-time the app runs.

One thing to keep in mind is that this is not 100% fool proof, as the user could manually delete the file. Thus you should not use this for security, serialization or trial tracking purposes.

Here is a simple example that shows how to enable your Adobe AIR application to accept native drag and drop operations.

This is a simple application that allows you to drag a text file into the application and then view its contents.

DragAndDropExample.mxml

<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication
	creationComplete="onCreationComplete()"
	xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">

	<mx:Script source="DragAndDropExampleClass.as" />

	<mx:TextArea top="10" right="10" bottom="10" left="251"
			id="outputField" />
	<mx:Text text="Drag a Text File into the Application"
			width="233" height="148" top="11" left="10"/>

</mx:WindowedApplication>

DragAndDropExampleClass.as

import flash.desktop.ClipboardFormats;
import flash.desktop.DragManager;
import flash.events.NativeDragEvent;
import flash.filesystem.File;
import flash.filesystem.FileMode;
import flash.filesystem.FileStream;

//called when app has initialized and is about to display
private function onCreationComplete():void
{
	//register for the drag enter event
	addEventListener(NativeDragEvent.NATIVE_DRAG_ENTER, onDragIn);

	//register for the drag drop event
	addEventListener(NativeDragEvent.NATIVE_DRAG_DROP, onDragDrop);
}

//called when the user drags an item into the component area
private function onDragIn(e:NativeDragEvent):void
{
	//check and see if files are being drug in
	if(e.clipboard.hasFormat(ClipboardFormats.FILE_LIST_FORMAT))
	{
		//get the array of files
		var files:Array = e.clipboard.getData(ClipboardFormats.FILE_LIST_FORMAT) as Array;

		//make sure only one file is dragged in (i.e. this app doesn't
		//support dragging in multiple files)
		if(files.length == 1)
		{
			//accept the drag action
			DragManager.acceptDragDrop(this);
		}
	}
}

//called when the user drops an item over the component
private function onDragDrop(e:NativeDragEvent):void
{
	//get the array of files being drug into the app
	var arr:Array = e.clipboard.getData(ClipboardFormats.FILE_LIST_FORMAT) as Array;

	//grab the files file
	var f:File = File(arr[0]);

	//create a FileStream to work with the file
	var fs:FileStream = new FileStream();

		//open the file for reading
		fs.open(f, FileMode.READ);

	//read the file as a string
	var data:String = fs.readUTFBytes(fs.bytesAvailable);

		//close the file
		fs.close();

	//display the contents of the file
	outputField.text = data;
}

One of the cool things about the API, is that you can have specific components within your application accept native drag and drop operations (and not just your entire app).

Note, right now, the app is not doing any checking to confirm that the file is a text file. If you try and drag a binary file into the app you will get weird results. (Im looking into how to check that the file is text based).

As part of my Flash on the Beach Intro to AIR Session, I built a simple HTML Editor with a live preview. I have added comments to the code, and uploaded it to the on AIR tour google repository.

This example demonstrates:

• Using the File API to write a string to a file
• Using the HTML Control within an application to render a string of HTML
• Using the File.browseForSave API to open a native save dialog.

Here is the code if you just want to glance at it:

HTMLEditor.mxml

<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication
	xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute"
	 viewSourceURL="srcview/index.html">
	<!-- include the code for the main app class -->
	<mx:Script source="HTMLEditorClass.as" />

	<!-- TextArea used to type in HTML -->
	<mx:TextArea height="172" top="10" left="10" right="10"
		change="onTextChange()"
		id="inputField" />

	<!-- HTML Control which we use for live preview of HTML -->
	<mx:HTML top="190" left="10" right="10" bottom="41" id="htmlField"/>

	<!-- Save button to save the HTML to a file -->
	<mx:Button label="Save" right="10" bottom="10" click="onSaveClick()"/>

</mx:WindowedApplication>

HTMLEditorClass.as

import flash.events.Event;
import flash.filesystem.File;

//called when the text / html is changed
private function onTextChange():void
{
	htmlField.htmlText = inputField.text;
}

//Called when the user selects a file to save
//html in.
private function onBrowseForSave(e:Event):void
{
	//get a file reference to the file the user selected
	var f:File = File(e.target);

	//create a file stream to write to the file
	var fs:FileStream = new FileStream();

		//open the file for writing
		fs.open(f, FileMode.WRITE);

		//write string of html to file
		fs.writeUTFBytes(inputField.text);

		//close the file
		fs.close();
}

//called when user presses save button
private function onSaveClick():void
{
	//get a reference to the desktop dir
	//this will be used as the default dir that the dialog
	//will open at
	var f:File = File.desktopDirectory;

		//listen for the select event for when the user selects
		//a file to save the html in
		f.addEventListener(Event.SELECT, onBrowseForSave);

		//open the browse for save native dialog, and pass in a title
		//for the dialog
		f.browseForSave("Save HTML File");
}

You can grab the code from the on AIR Tour code repository.

A lot of people have been asking whether the Adobe AIR beta currently works on Apple Leopard (OS X 10.5). I pinged the team and they they told me that they are currently doing some testing, and havent run into any major issues yet. However, we are seeing some reports of issues from developers online, so if you are currently working on an AIR app, you might want to wait a little while to upgrade until we have more information.

I installed AIR on Leopard, and all of my apps ran fine (although there were some minor issues with badge install).

I don’t have any information on Flex Builder, but I will try and install it and see if it works for me.

ars technica has an interview up with Ed Finkler, the developer behind the AIR based Spaz Twitter client (which was one of the winners of the AIR Developer Derby).

The interview is a good read and why Ed (an HTML / PHP developer) choose AIR, and what his experience was like working with the runtime. It also gives a good explanation of some of the new HTML / JavaScript security changes that were implimented in Beta 2.

You can read the entire article here.