This is probably the most important step to take when you are building your application and it should probably be the first thing you do. Let’s say someone found a bug in your application and you fixed it in a newer version. How are you going to tell users about that bug-fix if you don’t have an update mechanism in place? AIR has everything on board to make updating applications a breeze, both for you and the user of your application.

Whenever my application starts, it’s going to load an XML file from my server. That XML file describes the version I have on my server and I even added some release notes. This XML file can be structured any way you want it to be and can hold all the information you want in there. Working with XML files in AS3.0 and Flex has become a breeze compared to how it used to be. So no more firstChild.childNode[3].grandChild.bastardChild.attribute.version.

My application version XML file looks like this:
<?xml version="1.0" ?>
<application>
<info version="2" downloadurl="http://localhost/version2.air" />
<releasenotes>
<![CDATA[Fixed some bugs in this version]]>
</releasenotes>
</application>

Loading an XML file in Flex, is as simple as this one line of code:
<mx:HTTPService
id="appversion_xml"
url="http://localhost/onAIR/appversion.xml"
showBusyCursor="true"
resultFormat="e4x"
result="checkForUpdate()"/>

This creates an XML object with the name “appversion_xml”. Whenever the server sends back a result, the result event is fired which calls my checkForUpdate() function. I even show a little busy cursor to show the user that there’s something happening. E4X is the preferred result format. Now to load the XML file when my application starts, I created an init function.

private function init():void
{
	appversion_xml.send();
}

This gets called when my application is ready. Just add this attribute to your WindowedApplication node in Flex.

creationComplete="init()"

So the next thing you need to do when your XML file is loaded, is check if the version on your server is different from the one you have installed.

var descriptor:XML = NativeApplication.nativeApplication.applicationDescriptor;
var ns:Namespace = descriptor.namespaceDeclarations()[0];
currentVersion = descriptor.ns::version;

This would get the version number of the version you have installed. This actually refers to your application descriptor XML file. The application descriptor file gets included in your application when you build it and is accessible through NativeApplication.nativeApplication.applicationDescriptor.

The version number that I got back from the server will be available in:

appversion_xml.lastResult..info.@version;

Now I need to add a quick note here. The application version designator can be anything you want it be. It can be just a simple number but it can just as well be something like v3.79.3.222.beta.1.5.67.78. However, I find it a lot easier to use just plain and simple increasing numbers. These are a lot easier to compare to each other and thus make it a lot simpler for you to code.

if(Number(updateVersion) > Number(currentVersion)) {
	//update available
}

Now that’s a lot easier than having to create your own logic to compare your version designators.

So now that we know the version on my server is newer than the one I have installed so we have two options. You could just do the update without any user intervention, or you might want to let the user known that there is an update available and let him decide what he wants to do. In my demo application, I popup a little utility window that also displays the release notes from the XML file but you can let the user know about the options in however way you see fit.

We’re almost there. Now that we know the user wants to update the application we can go ahead and do so.
So the first thing we need to do, is download the new update to the local machine. Since we are using AIR we have access to the desktop and so we can do this automatically. In the code below, I create a new instance of a URLStream and attach an eventListener to it. Whenever the URLStream is done, it’s going to execute the code to store it on the user’s machine. In this case we are going to store the update in the applicationStorageDirectory and rename it to update.air. Next we create a new instance of the Updater class and call it’s update method specifying the path to our update and its version number.

private function downloadUpdate(file:String):void
{
   downloadStream = new URLStream();
   downloadStream.addEventListener(Event.COMPLETE, function(evt:Event):void {
      myUpdateWin.statusText = "Downloading and installing the update";

      var appData:ByteArray = new ByteArray();
      downloadStream.readBytes(appData, 0, downloadStream.bytesAvailable);

      var updateFile:File = File.applicationStorageDirectory.resolvePath("upgrade.air");
      var fileStream:FileStream = new FileStream();

      fileStream.open(updateFile, FileMode.WRITE);
      fileStream.writeBytes(appData, 0, appData.length);
      fileStream.close();

      var appUpdate:Updater = new Updater();
      appUpdate.update(updateFile, updateVersion);
   });
   downloadStream.load(new URLRequest(file));
}

The update method of the Updater class will close the application, launch the AIR installer to install the update and then relaunch the application. All without any intervention from the user! Completely transparent and easy for the end user.

That’s how easy it is to do it but to make it even easier, we’ve just released an update framework to simplify things even more. This framework works for both Flash/Flex based applications and Javascript/HTML based apps.

First of all, why is signing an application important? Easy. When your application is unsigned or signed with a self-signed certificate, the user will get two red icons on the install screen. The first one is related to your code signing certificate. It’s telling you that the “publisher is unknown” which is very normal since we have no idea who actually signed this application.

When you do get a code signing certificate and sign the application with it, the icon will turn green or in some cases yellow. The yellow icon will appear when you are using the file I/O API.

So where do you get a code signing certificate? Well, maybe you already have one. If you already bought one to sign Java or Cocoa applications for instance, chances are that this certificate is 100% compatible and you can use that. To make sure, check that your certificate is a Class 3 code signing certificate and you should be ready to go. If you don’t have, there’s a number of companies like Thawte.com that actually sell these. But if you upload your application to the Adobe AIR marketplace, you may get a complimentary code signing certificate from us. More info here.

I’m mainly using Flex for AIR development but the workflow is very similar in Flash or Dreamweaver. In case of Flex, you are actually going to build a release version of your application. To do that, you click the “export release build”-button. That will popup a little wizard window. In the first window, you can specify where you want to save your .AIR file. In this case, I’m saving it on the desktop.

When you click “next”, Flex will ask you to specify which digital certificate you want to use. If you don’t have one but still want to build a .AIR file for testing, click on the “create” button. When you fill out all the details of that form, you can save that self signed certificate so you don’t have to fill out that form every time. I saved mine in my home folder. Once you have created it, you can easily reuse it by just entering your password.

If you already have a code signing certificate, you can browse to the location you saved it to use it. Click “finish” and your AIR file is going to be baked. That’s it.