Home / Articles / Building Adobe WorkflowLab, Part 4: Planning for Build and Release

Building Adobe WorkflowLab, Part 4: Planning for Build and Release

Article Description

In part 4 of their series on the design and creation of WorkflowLab, Aaron Pedersen, James Polanco, and Doug Winnie, the authors of Adobe Flash Platform from Start to Finish: Working Collaboratively Using Adobe Creative Suite 5, discuss the planning process required to test the Adobe AIR-based application and considerations for distributing the app to users via the Internet.
Deployment Planning Strategy

Deployment Planning Strategy

The first requirement we defined focused on the deployment process: How would people get our application, and when? One of the requirements defined during our initial meetings was that WorkflowLab Alpha would be available on Adobe Labs at the start of MAX 2009. Users would download the application by clicking an AIR badge installer, which would support installing WorkflowLab and AIR (if the user hadn't installed it previously).

This requirement meant that we would need to create an AIR badge and any assets for WorkflowLab during the deployment and testing process. We also would need to have our assets and application ready two weeks before MAX, to give the Adobe Labs team enough time to post the assets and content.

Another requirement was that WorkflowLab would be auto-updatable. Therefore, we would need to integrate the AIR Updater into the application, as well as providing a publicly accessible XML file to define the current version of the application (see Figure 1).

Figure 1 The AIR Updater process.

The AIR Updater uses the XML file to determine the latest version of the software. If the version listed in the XML file was newer than the user's version, the XML file would also tell the application where the updated AIR file was located, so that WorkflowLab could download the new version of the software.

Because the XML file had to be publicly available and we needed the URL path to the file to stay the same from version to version, we had to work with the Adobe web team to define a special "go" URL that would always point to the correct XML file—even if the XML file later had to be moved. This approach would enable the developers to "bake" (code) the URL into the application, so that the file URL would still work even if the XML file changed locations sometime in the future.

3. Initial Signing Process | Next Section Previous Section