Today you can build Flex apps using the Flex application and component framework and deploy them to the desktop client with minimal code changes. Adding Central-specific functionality to a Flex application requires writing ActionScript to call specific APIs in the Central framework. As the two technologies become more closely integrated, however, the need for custom code to leverage desktop capabilities will decrease.
This product integration consists of two distinct pieces: ensuring compatibility between Flex and Central so you can leverage Flex functionality in an application deployed to Central, and ensuring compatibility between the Central and Flex compiler so you can reference the Central API capabilities in Flex applications.
Deploying a Flex Application to Central
Central is based on the Flash Player code base. This means that existing Flex applications, by and large, are ready to run. There are, however, some key differences between the Central runtime and the Flash runtime. This section presents a high-level overview of the developer workflow as well as things to watch out for.
Because Central surpasses basic runtime behavior by offering user interface patterns and non-visual application functionality, applications must do a little legwork to make the environment aware of their existence. This is similar to an application registry in operating systems.
For example, when your application initializes itself, it must register with
the Central environment by calling into the Central API: mx.central.Central.initializeApplication(this,
this);
To handle the callback from the Central environment, you must define and implement
the onActivate() method. You can add these method calls to the
class definition associated with your application as inline methods in the
initialize function
definition. When Central starts the application, it invokes this code.
You can also implement onDeactivate(), which gives you a chance to
run routines like cleanup or autosave when the user leaves your application
and it becomes invisible.
It's worth noting here one particular advantage of Central. Just because your application is not visible doesn't mean it's not running. Central applications can define background processes (called agents) and pods, which display at-a-glance information from your application. You create these in the same way that you create an application but you interact with corresponding namespaces within the Central framework.
To create an agent, for example, build a new Flex application and, instead
of the method call used above, use the methods specific to the agent manager: Central.agent.initializeAgent(this,
this);. The callbacks are the same.
Users install Central applications by navigating to installation badges on the web and clicking them. An installation badge is a SWF file on a web page. Badges for your use are included with the Central 1.5 SDK. When the user clicks the badge it detects the presence of the Central client, launches it if necessary, and passes information to Central about your application and its resources for downloading to the user's machine.
Information about what to install is contained within an XML manifest, called product.xml, which enumerates the resources (SWF files, image files, and so on) that make up your application and their locations relative to the badge. You can create the manifest using any text editor. Examples are included with the SDK as well.
Because Central runs locally cached copies of applications, Flex-generated apps, agents, and pods must be referred to as cached SWF files. For example, if your application is called MyAPP.mxml you should refer to it in your product.xml as MyApp.mxml.swf. This instructs the Flex compiler to deliver a cached copy of the application.
There's more information about proper product.xml formatting in the Central SDK. When you've created your product.xml file, simply upload it and your application resources to a web server.