To keep it simple and easy to follow, I use the first one. Updating an application and security One of the main benefits of the update framework is the ability to easily roll out updates to fix security issues.
It would be a little ironic if the framework itself didn't provide security when it is used, and instead allowed an installed application to be downgraded, for example. Fortunately, the update framework enhances the security of your application. For example, there is no way to "update" your application with an older version.
This means that there is no way to accidentally roll out a version older than the ones that are installed by your clients. The same version number must be set in the AIR file the AIR application packaged for release and in the updater descriptor file. Furthermore, an AIR application can't be updated unless it was signed with the same certificate as the one that is being used to update it.
Keep in mind that the update framework needs a connection to the Internet or your local network. The new version and the updater descriptor files sit on a web server. Thus, when the application checks for updates it needs a connection to reach these files.
If there is no connection, no update will be possible. Because the Adobe AIR update framework is flexible, you decide how best to handle the update process. Your process can implement any of the following approaches: When the application is started, have it check whether a new version is available.
Check for new updates at defined time intervals. Let the user decide when to check for a new version, download the update, and install the file. Alternatively, you can enforce all these actions. Notify the user what fixes or new features the update provides. If you use CSS files to change the appearance of your AIR application and you use general styles for example, for the Button or Scrollbar that are not set as a class name but apply across your application, then these changes will also apply to the UI provided by the update framework.
If you don't want to create the project step by step, you can use the archive file provided with this article. Adding the update framework library to the project Create a folder inside of your web server root named updater. Add this folder to your project in order to be able to create and edit the content easily. In the wizard, select Advanced and then select Link to folder in the file system see Figure 4.
On my computer, the Apache web root is c: In this folder you will place the updater descriptor file and the application's AIR file. Creating the link resource Creating the Flex code With all the bits in place, it is time to add the ActionScript to implement the update feature: Then create the function checkUpdate , which will be in charge of initializing and setting some values needed by the updater object. The updateURL property tells the updater where to find the updater descriptor file you will create this file later.
If you don't set the updateURL property correctly, the update will not work. Next, you'll need to register two functions for the error event and initialized event.
If the isCheckForUpdateVisible property is true, then the user is given the option to check for a new version or not. In this case, set it to false, which will bypass this dialog box when checking for a new version. The last function call, appUpdater. When the updater is initialized it calls the listener you have registered for the initialize event, and inside this listener you start the process of checking for a new version.
The next two functions are the implementations for the event listeners for the error and initialize events. Once the onUpdate listener gets called, it means the updater was initialized and it is ready to take commands.
The onUpdate function calls the method checkNow on the updater, starting the update process. The last function, setApplicationVersion , just reads the current version of the app and displays it using a label. Finally, add a label component to display the current version of the application: First create the file update.
Testing the code All the code is in place but you are not finished yet. It is very important not to forget this: In both these files you will find a version tag; what you put here needs to be exactly the same.
First, export the existing AIR application for release, and then install it. Now, you are ready to test the update: In both files set the same version number make sure it is higher than the current one , for example 2. Export the project for release and place it in the same folder as the update.
Finally, start the application. You should see a dialog box example in Figure 5. Again, I am too lazy to create a UI. And again, you can create the AIR application in your favorite text editor and use the command-line tools to test and package. However, I prefer to use Aptana. After creating the project, add the external folder updater , the folder that holds the new version of the application and the update descriptor file see Figure 4 and the associated explanation on how to do this.
I will reuse the same folder c: To add this library to the application: Inside this function, you configure the updater object: The last line of this function initializes the updater object. After the updater object is initialized, the onUpdate function gets called and the object is ready to take commands.
At this point, the code calls the checkNow method on the updater object to start the update process if a new version is found on the server. Lastly, you need to hook up the call to the checkUpdate function to the onload event of the application: First create the update. Add this code to the file: On my machine the URL to the updater folder is http: Testing the code With the code in place, you are ready to test it.
First, you need to export the application and install it on your machine.