Lots of excitement at the Adobe booth at Mobile World Congress in Barcelona. Our announcement about Flash Player 10.1 and AIR for mobile devices is definitely buzzing!

Photos shot with a Google Nexus One.

After a very successful and fun tour though the UK, SOTR is now going to mainland Europe. Most of you  know that my love for ColdFusion is growing with every project I do using it. I think you can really only appreciate ColdFusion after getting a taste of it and SOTR is the perfect place to get that taste. With SOTR Europe being a free event, there really is no excuse to not be there. ;-)

Hope to see you in Munich, Zurich, Milan, Amsterdam, Brussels or London!

More info and free registration on http://www.scotch-on-the-rocks.co.uk

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.

You created your AIR file… so now what? The easiest thing to do is to upload the file to your server and put a link to it on your website. But this is not very user-friendly for whoever is going to download and install your application. In some cases, when your server isn’t configured to handle AIR files, it may even fail altogether. That’s why we created the concept of install badges. Install badges are basically a small Flash application that handles download and install in such a way that it becomes very easy for the end user to install your application.

There are 3 different flavors of the install badge: The standard version, the “currently in beta” version and the custom install badge.

The standard install badge is part of the AIR SDK. If you download and extract that zip file, there’s a folder called samples that includes a ready-to-go sample. Just change some parameters in the source of the html, upload the files and your AIR file to your server and you’re done. I have to be honest and tell you that I don’t really like the standard badge. It’s fine if you just want a simple install badge but the beta badge is so much better.

The beta badge is available on Adobe Labs. It is actually created by Grant Skinner. The first thing you notice when you launch the sample, is that it has a much cooler/smooth look. But this badge also has a bunch of extra features that the default badge doesn’t have. For one, this badge can determine if the application is already installed and then prompt the user to launch the application right from within the browser. It also detects if the user has the correct version of the runtime installed; if not, it will offer to download it. This badge also allows you to add a little bit of support information when the user clicks on the question-mark icon. But my favorite feature is that this badge uses SWFObject which is my preferred way of adding SWF content to a web page. If you compare the source of the default and beta badge, you’ll see that SWFObject and the way it handles FlashVars is a lot more readable compared to the name-value pairs in the default badge.

The third option would be to build your own install badge. Don’t worry… you don’t have to start from scratch. The sources for both the default and beta badge are available so you can use these as the basis for your own. It’s as simple as that ;-) The great thing is that this can be anything you want to it to be and can have all the features you want it to have ’cause well… you are building it. If you want to ping your server whenever someone starts the install of your application for instance, that is absolutely possible.

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.