Using Macromedia Central to Target Occasionally Connected Computers (OCCs)

[ LiB ]

Macromedia Central is basically a standalone projector that gets installed on the user 's machine, but with several unique properties. First, the installer is entirely contained inside the newer Flash players (version 6,0,65 or later); so, the first time a user visits a site containing a Central app, the 1MB Central projector gets installed automatically. That is, you still create your app as a Flash SWF, but it runs inside the Central projector, which is easily installed. This removes the need for users to trust your site. Also, after users download the main Central projector, they can download and install additional Central apps by just downloading the SWF. Central manages all your installed apps. Figure 2.3 shows how I can launch any of the six apps I have installed.

Figure 2.3. Macromedia Central includes a button bar for quick access to any installed app.

One of the cool ideas with Central is that a single app can have several components . For example, "pods" are like mini-apps that are small enough for users to leave visible at all times. Also, " agents " are code that runs in the background. Because Central apps can easily reach out and grab data on the Internet, a pod and agent combination can monitor a stock price (to take an overused example) and even alert you when a price reaches a certain level.

Once installed, your app lives in the company of all other installed Central apps on the user's machine. Therefore, your app should "play nice" by ensuring messages sent between agent and pod don't cross wires with other app's agents or pods. On the positive side, Central set up a vehicle that enables users to select data collected by one app (say a stock price) and send it to another app (maybe a graphing tool). Such collaborative apps offer a future where there aren't any "killer do-everything apps" (and instead just app modules that users can snap together to make their own killer app)!

Central really does offer some cool possibilities. Although it's only in its first edition now, its future will be determined by the supply of great apps. After all, Central is only a container. If developers make cool apps that everyone wants, Central will take off.

A couple more details can help you gain a perspective on Central. I mentioned earlier that projectors are given additional privileges that could certainly mean a risk to security. In the case of Central, Macromedia has enforced the same security model used in Flash. One exception is that you can also load media or data from domains outside your own. However, an app I write can't see or modify data saved by your appunless the user consciously decides to share it. Basically, Central is Flash Player 6 (with a couple extras). So, Central is equivalent to Flash in both what it can and can't do.

Because Central is on the user's hard drive, it can run when the user is not online. Your app downloads and then, presumably, connects to the Internet. Users who've indicated they're offline will be sending an event to your app so that it doesn't bother connecting to the Internet. You can certainly do plenty of useful things if you plan your app with this in mind. A user could work on his workgroup calendar, for instance, and your app could then make updates to the data online during a synchronization process the next time he's connected.

Although there are only a few technical on/offline issues to consider, the real work is in designing your app to be interesting both on- and offline. The concept of such on/offline users is being called OCC (for occasionally connected computer). Realize that although this includes jet-set business persons with their fancy wireless Intel Centrino laptop, you can also include modem users who are occasionally connected. This increases both your potential audience and suggests new ideas for applications.

Incidentally, the vehicle to send data between separate components of your application is Flash's local connection object. Chapter 6 "Basic Data Exchange," covers this in detail. Saving preferences between sessions is handled through the local shared object (also covered in Chapter 6). The good news with these technologies and any other supported in Central is that they're basically all Flash. You can leverage your Flash skills to build Central apps.

Finally, if you do want to make a publicly available app and make money selling it, you're welcome to use Central's built-in merchant features. There's a try/buy mechanism that you can use to get people hooked during, say, a 30-day trial period. The user can pay through Central, and Macromedia will send you the money directly (after taking their cut). You don't have to use this feature, but it offers more than just a way to make money. Your app immediately has the credibility of Macromedia.com behind it (instead of the fly-by-night impression from somewhere such as phillipkerman.com). Additionally, you can register your product so that it automatically appears in Central's Application Finder tool. This way users don't have to stumble across your web sitethey'll see your app listed as in Figure 2.4.

Figure 2.4. Central's Application Finder means users have a single place they can browse for applications.

I really think Central is neat. It fits well into this book's topicbut it's only part or the RIA picture. For this reason, you won't find a separate chapter dedicated to Central. However, throughout the book I mention how Central fits in where appropriate. Here, it fits into design insofar as you need to know what's possible to design an app that's useful.

[ LiB ]