Tuesday, March 30, 2010

Part 2, Deploying Adobe AIR apps in a corporate environment

Before we get started creating installers for Windows and Mac that will silently install and update both the AIR runtime and our app, it is important to understand a few concepts about how AIR apps get installed on Windows and Mac.

Explaining Mac is easier. The AIR app is associated with a Bundle ID, in Mac terminology. The Bundle ID looks like something like this:

HelloWorld.e146c51663394ee63585200f02ce0969fc8dd73c.1


When you look at an AIR app in Finder, it looks like a file, but it is actually a directory, and you can see the contents by right-clicking and selecting Show Contents. In Terminal, you can just cd to the Contents sub-directory. When you create your AIR file with Flash Builder or ADT command line, you can choose files and directories to bundle with you main SWF, and these get compressed into the AIR file, and decompressed into the Contents directory of the installed app.

On the Mac, the user can move apps around, since it is just moving or copying a directory. Unlike Windows, where locations of apps are stored in places like the Windows Registry and moving an app means it probably won't run in the new location, most Mac apps will run if you copy or move them elsewhere. Of course, you may need admin rights to move to/from certain directories.

Given that you can relocate an AIR app on Mac, how do you find it so you can uninstall it? The answer is the LSFindApplicationForInfo function. You pass the Bundle ID to LSFindApplicationForInfo, and you get back a URL to your app. The URL is hard to work with, so you can turn it into an absolute file path with a call to CFURLGetFileSystemRepresentation.

This means writing C code for Mac! I'll show you how to use XCode (which is free) to create a small command line app for Mac. We will do something similar for Windows with a C++ app written in Visual Studio 2008 (or Visual C++ 2008 Express Edition, which is free).

So on Mac, once we have used the AIR app Bundle ID to locate it's URL, and transformed the URL to a file path, uninstalling the AIR app on Mac is just the command line:

rm -rf path


Of course, you may need admin rights to remove the directory, so just precede the rm command with sudo. Note that this is analogous to the manual way of removing an AIR app on Mac, which is to just drag it to the Trash Can.

So, to uninstall an AIR app on Mac, you need the Bundle ID. How do you get the Bundle ID? The Mac Bundle ID is the same string as the Mac OSID for you AIR app, and you should use the OSID Generator to get both the Mac OSID and the Windows OSID (discussed later) for you app. The OSID Generator is a small AIR app that you get access to when you are accepted to Adobe's redistribution license for the AIR runtime.

The OSID Generator takes two inputs, the Application ID and the Publisher ID of your AIR app.

The Application ID is in your Flash Builder project in the <project_name>-app.xml file. You should never change this, because it needs to be constant to keep your Windows and Mac OSIDs constant, and you need these to be constant to uninstall you app. You can also get the Application ID from an installed AIR app in application.xml file found in the the META-INF/AIR sub-directory of your app installation directory.

The Publisher ID can be found in the publisherid file in the META-INF/AIR sub-directory of your app installation directory. Note that you AIR app must be code-signed with a real security certificate (not a self-signing certificate) to get the Publisher ID.

You will need to manually install your AIR app (clicking on the AIR file) to get the publisherid file that contains the Publisher ID. Like the Application ID, you should never change the security certificate, because then you get a new Publisher ID (at least I believe that is correct), and the Publisher ID is used to generate the

If your AIR app is an internal app, you may get some resistance to the expense and trouble of code signing. There are lots of good reasons to sign apps distributed over the public Internet, and I think some of those reasons apply in corporate environments, but the biggest argument for signing your app is you must sign it if you wish to be able to silently update or uninstall the app (remember from my last post that a silent update is really a silent uninstall of the old version and a silent install of the new version).

Here is the argument for signing your AIR app, step by step:

  1. To silently upgrade or uninstall an AIR app, you need the Mac OSID or Windows OSID, depending on the OS.
  2. The OSID is generated off the Application ID (which you know) and the Publisher ID.
  3. To get the Publisher ID, you must sign you AIR app with a real security certificate.
  4. Thus, in order to have the ability to silently upgrade or uninstall an AIR app, you must sign the AIR app with a real security certificate.
If you do not have a security certificate yet, you can still practice creating an installer with an AIR app which is signed, and there are plenty of those available on the web, just Google. Just manually install the AIR app and look in the META-INF/AIR sub-directory for the Application ID and Publish ID (as described above) to plug into the OSID Generator to find the OSID for Mac and Windows.

On to Windows, the concepts of how an AIR app is installed and uninstalled are a little more complicated. On Windows, an AIR app is installed and uninstalled using Windows Installer. Oliver Goldman explains it all very well in this blog entry. The only thing I can add is that what Oliver calls Upgrade Codes and Product Codes are also referred to as Upgrade GUIDs and Product GUIDs in other documentation.

For those who don't know, a GUID will look something like this:

{8209FAF5-4714-5CB1-20B5-9D840B252637}
To paraphrase Oliver, your AIR app is associated with a Product GUID that changes with every build of your AIR app, and an Upgrade GUID that does not change. In fact, the Windows Upgrade GUID is the same string as the Windows OSID for you AIR app, and you use the OSID Generator to get the Windows OSID as I described above for Mac.

Once you know the Upgrade GUID, you can call a Windows function MsiEnumRelatedProducts
to get the corresponding Product GUID, and you can then uninstall the AIR app with the following command line (run as Administrator):

msiexec /x ProductGUID


To call MsiEnumRelatedProducts on Windows requires native code, and Oliver has a small C++ program with his blog post that works fine, and which I use, though I made just one small change, which I will get to.

Note that calling "msiexec /x" is analogous to manually removing an AIR app in Windows via Add/Remove Programs (or Programs and Features) in Control Panel.

Now that I have covered the concepts, next post I will get into building the actual installers.

One more quick note, see this article on how to manually uninstall the AIR runtime and an AIR app for both Windows and Mac. You will be doing a lot of this as you test your installers.

No comments:

Post a Comment