So, you have built version 1 of your AIR app and you want to publish it, but you know that you are going to release more versions of it in the future. So, what do you do? You make your AIR app updateable.

In the last post I just pretty much just provided source files for programming your AIR UI and custom menus as it was self explanatory, however in this post I am going to have to go into a little more detail. In a while the AdobeTV Flash Downunder episode on this will go live and will explain it much better as I step you through the process, but for now I will try and explain a few of the ‘gotchas’ that aren’t necessarily clear in the source files.

Also, for this example I am using the default Application Updater UI interface. This is one that already exists and is simple to implement. You can also create your own custom interface, however this example does not cover that.

As an overview, you want to do the following:

• tell your AIR app to check for updates and tell it where to look on the web for the updates
• create a place on a web server that contains the latest version of the app and an xml file that describes the latest version
• and finally, if an update is available provide an interface for allowing the user to do the update

So, in more detail:
Ideally you are using Flash CS4 and have done all of the updates available from the Adobe website. This means that you are using AIR 1.5. If not you should do these updates first.

In your version 1 (and version 1.1 etc) AIR .fla (or .as) file import the following 2 classes:

import air.update.events.UpdateEvent;
import air.update.ApplicationUpdaterUI;

The reason I mention this specifically is that as well as importing the classed you also need to point your .fla to the applicationupdater_ui.swc file as well or it won’t work.

To do this open the Publish Settings panel, select the Flash tab, and next to Script: select ActionScript 3.0 and then click on the Settings… button.

Then click on the Library Path tab. Click on the red folder icon – Browse to SWC file.
You then need to navigate to where the .swc file lives. On a Mac this is usually:
/Applications/Adobe Flash CS4/AIK1.5/frameworks/libs/air/applicationupdater_ui.swc

NB. make sure you choose the one with the _ui at the end. If you want to create your own custom UI then you would choose the one without the _ui.

Once you have selected it click OK and OK again in the Publish Settings panel. OK, thats ‘gotcha’ number one out of the way.

Next you add the code that I have at the beginning of each version of the app that checks to see if a new version is available:

var updater:ApplicationUpdaterUI = new ApplicationUpdaterUI();
updater.configurationFile = new File("app:/update_config.xml");
updater.addEventListener(UpdateEvent.INITIALIZED, updaterInitialized);
updater.initialize();

function updaterInitialized(e:UpdateEvent):void{
	updater.checkNow();
}

Now, you’ll notice that on the second line of this there is reference to an XML file called “update_config.xml” and that its path is the app itself. This file is an XML file that you add to your AIR app under the AIR – Application and Installer Settings panel.

Open the panel and at the bottom where it says Included files: click the + button and point to the XML file. ‘Gotcha’ number 2. This is all that needs to be done in the AIR .fla file itself.

So, what about the XML file we added to our app? Well it tells the AIR app where to look for updates.

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns="http://ns.adobe.com/air/framework/update/configuration/1.0">
     <url>http://www.yourwebaddress.com/update_descriptor.xml</url>
    <delay>1</delay>
    <defaultUI>
       <dialog name="checkForUpdate" visible="false" />
       <dialog name="downloadUpdate" visible="true" />
       <dialog name="downloadProgress" visible="true" />
       <dialog name="installUpdate" visible="true" />
   </defaultUI>
</configuration>

So, the way this XML file is configured, it will check for updates whenever the AIR app is run but it will only pop-up a window for the update if there is one available.

OK, so now you can publish version 1 of your AIR app and distribute it.

So, now you are ready to release version 1.1.
You do exacltly the same as above in version 1.1 of the AIR app itself – nothing different – but don’t forget to do it in every version!

Next we need to get teh server files sorted.

Wherever you told the AIR app to look for updates on the web, you need to place another XML file – ie the “update_descriptor.xml”. It looks like this:

<?xml version="1.0" encoding="utf-8"?>
<update xmlns="http://ns.adobe.com/air/framework/update/description/1.0">
  <version>1.1</version>
  <url>http://www.yourwebaddress.com/updates/AIR_updater.air</url>
  <description>This is Version 1.1 of the application.</description>
</update>

You’ll notice that this XML file has 3 settings:

• version gives the number of the latest version available
• url is the web address of the latest version of the AIR file
• description is a description that you want users to see so they know why they should update the app

All you need to do is place this XML file on the server and the latest version of the AIR app with it. This XML file will need to be updated every time you release a new version of your AIR app.

When the user runs version 1 of the AIR app, it will run for a second…and if there is a new version available this window will pop-up…once the user follows the instructions AIR will do the update and run the new version.

Very simple! I hope this is clear enough. I have posted all the source files so you can download them and play.

Also here is version 1 of the demo AIR app. If you download and run it it will then start the update process so you can see for yourself.