Providing Version Synchronization for Deployed Rich Internet Applications

The Situation

There are a few fundamental concepts to understand about Flex and Flash before getting started:

• Flex applications are written in a combination of MXML and ActionScript, and reside on the server
• Flex creates applications that run in Macromedia Flash Player
• When a client requests a Flex application, the Flex server either just-in-time compiles the application or returns a cached version
• Once clients access the Flex server, they have a copy of your compiled application in their cache; it is not running on the server
• After clients download this copy, you do not have any intrinsic way to force them to retrieve a modified version of it

The CEO of My Virtual Pet, Inc. (MVP for short) shakes your hand, welcomes you on board, and reiterates his well-founded confidence in your ability to make their award-winning Virtual Pet software into a Rich Internet Application.

Along with your detailed specification, and a last-minute warning that MVP intends to keep ahead of their competition by releasing a new behavior for their pets every few days over the next year, you head back to your trusty computer and start designing.

With your design pattern book in hand, you map out your classes and conclude that the basic implementation is a piece of cake. You see really only two problems:

• If users keep this Virtual Pet application open on their computer all day, every day, how are you ever going to add those new behaviors every day?
• What happens if, somehow, in your seven-day project timeline, you create a bug that is not discovered during testing?

The Problem

Instead of filling this article with implementation details for the Virtual Pet application, I assume that you will design the pets to the MVP specification. To demonstrate the version synchronization topics, you will use a simple class (Dog) to represent that work.

Find the sample code in virtual_pet1.mxml, located in the accompanying file downloaded in the Requirements section of this article:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml" xmlns="*">

   <Dog id="myPet" 
        title="Virtual Pet RIA">
            petName="Spike"/>

</mx:Application>

This is your starting point: a simple application that instantiates a Dog. The Dog class puts a picture of the dog on the screen and lets him introduce himself (see Figure 1).

Figure 1. Dog class introducing itself as Spike

Today Spike can bark, wag, and roll over but you need to ensure that Spike can learn new tricks in the future. Therefore, you need to provide a mechanism for future updates.

There are two groups of Virtual Pet users. Some users close down their web browsers or turn off their computer every day. Flex automatically takes care of these users because when they return to the MVP website, Flex provides them with the latest version. The other set of users keep their web browsers open for the life of their pet. They are your focus at this point.

Potential Solutions

The always-connected users do not intend to close their web browsers or go back to the MVP site. There are two relatively easy ways to deal with them.

• Redirect users once a day to the MVP website and let Flex provide them with the latest version. Users would be sent back to the website every day. If there was a new behavior available, they would receive it. If not, however, they would be inconvenienced. Furthermore, if you found a critical bug, or if you decided to release a new critical change, you would need to wait until the next day before most users would receive the update.
• Redirect users back to the MVP website—but intelligently decide when it is necessary to do so and perhaps allow some input from users. For example, if they (or their pets) are busy, wait to update them until a more convenient time. Although users would still be sent back to the website, they would be inconvenienced only if you had something new to offer them. This is a much better situation. Furthermore, if they can choose to defer this process, they maintain a level of control over the updates.

Page 2 of 4

Previous Page

Next Page