Flash Remoting: The Definitive Guide

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

When I was an 11-year-old kid, I thought I was pretty good on a bike. I could do wheelies around the neighborhood, drive on dirt hills, jump ramps. It wasn't enough, though. I wanted to make the transition to a minibike, which is basically a little bike with a lawn mower engine on it. If all I needed was my riding skills, I probably would have been set. Unfortunately, keeping my feet in one place, turning the throttle, and pressing the hand brakes on the minibike were unknown territories. My first time out I turned the throttle too far, lost my footing, and forgot how to hit the brake. I landed in a heap in the street.

If I had put a little forethought into it, I would have realized that riding a bike and riding a minibike were completely different things. Only some aspects were the same; by learning the new aspects and applying my prior knowledge of riding a bike, I eventually figured out how to stay put without falling on my butt.

Working with a new computer technology in a familiar environment is like that. In the case of Flash Remoting, everyone holding this book is probably familiar with Flash movies and ActionScript programming. Flash Remoting puts some new and exciting things into Flash that will require learning new ways to look at ActionScript and what it can accomplish. With Flash Remoting, Macromedia has put an engine on Flash.

These are exciting times. Macromedia is attempting to change the way application developers create web-based applications.

Flash Remoting constitutes a complete rethinking of how web applications are constructed. Using Flash Remoting, you can create complex client/server applications that more closely resemble desktop applications than traditional web pages. For those of you familiar with traditional Windows-style programming IDEs, Flash Remoting is roughly the web equivalent of a Visual Basic client/server application. This chapter presents a broad overview of Flash Remoting.

Flash Remoting technology is at the center of Macromedia's Studio MX product suite, linking the server platforms with the client-side tools. Flash Remoting is built into Macromedia's two application servers—ColdFusion MX and JRun 4. In addition, programmers using other technologies, such as ASP.NET or J2EE application servers, can purchase the Flash Remoting MX package so that Flash Remoting can be utilized on those servers. Although Macromedia doesn't officially support other languages, open source implementations are available for PHP (the AMFPHP project at

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

These are exciting times. Macromedia is attempting to change the way application developers create web-based applications.

Flash Remoting constitutes a complete rethinking of how web applications are constructed. Using Flash Remoting, you can create complex client/server applications that more closely resemble desktop applications than traditional web pages. For those of you familiar with traditional Windows-style programming IDEs, Flash Remoting is roughly the web equivalent of a Visual Basic client/server application. This chapter presents a broad overview of Flash Remoting.

Flash Remoting technology is at the center of Macromedia's Studio MX product suite, linking the server platforms with the client-side tools. Flash Remoting is built into Macromedia's two application servers—ColdFusion MX and JRun 4. In addition, programmers using other technologies, such as ASP.NET or J2EE application servers, can purchase the Flash Remoting MX package so that Flash Remoting can be utilized on those servers. Although Macromedia doesn't officially support other languages, open source implementations are available for PHP (the AMFPHP project at http://www.amfphp.org) and Perl (the FLAP project at http://www.simonf.com/flap). There is also an open source Flash Remoting for Java implementation (OpenAMF at http://www.openamf.org).

The Flash authoring environment includes UI components, which form the basis of Macromedia's strategy of using a Flash movie as the client in a client/server atmosphere. This approach allows the application server to provide the programming power for the application. Using Flash Remoting, a Flash movie can act as the interface for diverse applications, including connections to databases, SMTP mailers, server components, web services, and much more. Flash Remoting ties together the Macromedia authoring tools and application server technologies to form a new approach to web application development and deployment.

Flash Remoting is a server-side technology that integrates with existing application servers to provide a gateway between the Flash Player and remote services deployed on the server. A

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Flash Remoting gateway is installed on the application server and acts as an interface between the Flash Player and the server. The Flash Remoting software that implements the gateway is also called an adapter. It has three main tasks:

Handle requests from the Flash Player to remote services. These services can be on the same server as the Flash Remoting gateway or can be external to the server in the form of web services.
Translate requests and data from the Flash Player into server-side requests and datatypes.
Translate responses and data from the server into native ActionScript datatypes.

Figure 1-1 depicts the Flash Player/Flash Remoting architecture.

Figure 1-1: The Flash Player/Flash Remoting architecture

Communication between the Flash Player and the Flash Remoting gateway is done via HTTP, which has a few implications:

Communication between the Flash Player and the Flash Remoting gateway is request-driven. The Flash Player must initiate all communication with the Flash Remoting gateway. The server cannot push data to Flash unless it is requested by the Flash Player. Use the ActionScript XMLSocket object, as discussed in ActionScript for Flash MX: The Definitive Guide (O'Reilly), if you need to push data from the server to Flash, such as in a chat application. Another option is to use Macromedia's Flash Communication Server MX (FlashCom) for these types of applications.
HTTP is a stateless protocol, so each request from the Flash Player opens a new connection to the server.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

One of the key benefits of using Flash Remoting over XML or traditional HTML applications is that the application server no longer needs to handle any of the parsing or presentation of information. This frees resources on the server so that it can be better equipped to deal with more complex application logic and/or more users. In addition, session management can be handled on the client inside of the Flash movie rather than on the server. The server still keeps track of the session, but the developer doesn't have to jump through hoops to keep track of users who don't have cookies or track a user session across multiple pages. This equates to huge savings in development time and server resources.

I've talked about the benefits of Flash Remoting, but why not use XML? After all, using XML you could encapsulate all of the client/server communication within an ActionScript object and provide a simple API to transfer complex datatypes serialized with XML between Flash and the server. This would have the advantage of not requiring a server-side gateway and would work with Flash Player 5.

The main advantage of Flash Remoting over XML is that it relieves the developer from writing an entire layer of code on both the client and server. XML parsing is built into many of the popular server technologies, but it is cumbersome at best. However, Flash Remoting also has a number of additional advantages:

It automatically handles all datatype conversions between ActionScript and the server.
It can convert multiple complex datatypes.
It seamlessly supports multiple server-side technologies and application servers.
It allows remote services and web services to be called directly from Flash without requiring any additional server-side code to be written.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

To develop Flash applications that use Flash Remoting, you must have:

Macromedia Flash MX or later
The Macromedia Flash Remoting components
A server that has the Flash Remoting gateway or the equivalent (such as AMFPHP, FLAP, or OpenAMF)

The Flash authoring environment is used to create Flash files (.fla and .swf files) and applications. Flash MX was a substantial upgrade to previous versions of Flash. In addition to cosmetic interface changes, the way in which Flash applications are developed has changed. Flash MX or later is required to develop Flash Remoting applications. A fully functional trial version is available from Macromedia at:

http://www.macromedia.com/software/flash/download/

You can find more information on Flash at:

http://www.macromedia.com/software/flash/

As of Flash MX, Macromedia abandoned a consistent version-numbering scheme for the authoring tool, but the Flash Player is still assigned a numeric version. Flash Remoting requires that you publish your .swf files in Flash 6 format or later.

Director MX, a separate multimedia authoring tool sold by Macromedia, can access Flash Remoting using the Flash MX Asset Xtra (which is basically an embedded version of Flash Player 6). For simplicity, this book assumes you are running Flash in a browser or a standalone Projector.

Flash MX does not come with the Flash Remoting components preinstalled. The Flash Remoting components add support for Flash Remoting to the Flash authoring environment and are required to create Flash files that take advantage of Flash Remoting. If you're using Director MX as the front end, you'll need the Flash MX Asset Xtra, which is compatible with Director MX or Shockwave 8.5.1 or later. The Flash MX Asset Xtra includes Flash Remoting support.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This section is a quick summary of Flash Remoting capabilities and server-side services that can be exposed to Flash from supported application servers. For the latest list of supported application servers, platforms, and configurations, see:

http://www.macromedia.com/go/flashremoting

The Flash Remoting gateway comes preinstalled with Macromedia ColdFusion MX and allows developers to deploy remote services as:

ColdFusion pages
ColdFusion Components
Server-Side ActionScript (SSAS)
SOAP-based web services

Flash Remoting is also included in the Macromedia ColdFusion MX for J2EE version for deployment on Java application servers, such as WebSphere and BEA WebLogic. It includes support for the remote services supported in ColdFusion MX in addition to those supported on a Java server that ColdFusion is installed on, as discussed below. For more information on ColdFusion MX, or to download a fully functional trial version, go to:

http://www.macromedia.com/software/coldfusion/

See also Programming ColdFusion MX, by Rob Brooks-Bilson (O'Reilly), for information on ColdFusion. The trial/developer version of ColdFusion MX can be obtained together with Flash MX in the Macromedia Studio MX bundle.

The Flash Remoting gateway is available as a standalone product for any J2EE-compatible application server. It also works with a Java servlet engine that has been certified compatible with Sun's servlet 2.2 or 2.3 specifications, such as Tomcat. Flash Remoting for J2EE allows remote services to be deployed as:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

An introduction to any technology would not be complete without a "Hello World" example. This will give you some hands-on experience with the client-side and server-side code before diving into details. It also provides a sound basis for exploring Flash Remoting on your own.

First, we will look at the Flash code necessary to call the remote service, which is virtually the same regardless of which server-side technology implements the service. We will then look at the server-side code implemented in ColdFusion, Server-Side ActionScript, Java, ASP.NET, PHP, and as a SOAP-based web service.

The examples throughout the book assume that you have Flash Remoting installed and configured on your server, and that you have installed the Flash Remoting components for Flash MX. Chapter 2 covers Flash Remoting installation and configuration in more detail.

The client-side ActionScript is virtually the same for each server-side service example. The only things that change are the path to the remote service when it is implemented as a web service and the path to the Flash Remoting gateway, which varies depending on the server implementation.

The client-side ActionScript code shown in Example 1-1 should be inserted on the first frame of the main timeline of a Flash movie, as shown in Figure 1-4.

Figure 1-4: Flash timeline with attached client-side ActionScript

Example 1-1. Client-side ActionScript code (HelloWorld.fla)

/*** Section 1 ***/
#include "NetServices.as"

/*** Section 2 ***/
// Assign myURL so it points to your Flash Remoting installation.
var myURL = "http://localhost/flashservices/gateway";
var myServicePath = "com.oreilly.frdg.HelloWorld";

/*** Section 3 ***/
myResult = new Object( );

myResult.onResult = function (data) {
  trace("Data received from Server : " + data);
};

myResult.onStatus = function (info) {
  trace("An error occurred : " + info.description);
};

System.onStatus = myResult.onStatus;

/*** Section 4 ***/
var myServer = NetServices.createGatewayConnection(myURL);
var myService = myServer.getService(myServicePath, myResult);

myService.sayHello( );

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Having discussed how the Flash Player and the Flash Remoting gateway communicate, now let's look at what occurs behind the scenes. We will examine each step of the earlier Hello World example. In Example 1-1, a remote service was called from Flash and received a "Hello World" string in response.

Here are the steps that occur:

Using the NetServices API within Flash, developer-written code makes a call for a remote service.
The NetServices library passes the remote service call, along with any arguments, to the NetConnection object within the Flash Player.
The NetConnection object serializes the request into AMF and sends it to server as an HTTP binary POST.
The Flash Remoting gateway on the server receives the request, deserializes it and determines the server-side service to which to pass the request.
The Flash Remoting gateway on the server invokes the server-side service, passing any arguments sent along with the request from the Flash Player.
The Flash Remoting gateway on the server receives any data returned from the service (in this case, the string "Hello World"), serializes it into AMF, and returns it to the client-side Flash Player as an HTTP response.
The Flash Player receives the AMF data from the server and deserializes it into a native ActionScript datatype (in this case a String object). Depending on the data sent back, the deserialization is done within the Flash Player or the NetServices code.
Finally, the string is returned to an ActionScript callback function specified by the developer to receive data loaded from the server.

Although a lot happens when a remote service is called from the Flash Player, most steps are abstracted away from the developer. The developer has only to write the client-side ActionScript that calls the remote service (Step 1) and receive the response from the remote service (Step 8). Of course, someone has to write the code for the remote service itself (Step 5), but that is often done by a different developer or independently of Flash, such as in the case where a Flash front end is being added to an existing web service.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

We conclude this chapter with a general overview of a client/server architecture using the Flash Player and the Flash Remoting gateway. Generally, Flash/server applications follow an n-tiered architecture. Figure 1-7 depicts such an architecture, comprising a client/presentation tier (the Flash Player), a middle tier (Flash Remoting gateway running within an application server), and a data tier (a database, XML file, or other data source).

Figure 1-7: The Flash/server n-tiered application architecture

The presentation tier is responsible for the application's user interface (UI) and any client-side logic that is needed, such as client-side data validation. It communicates with the middle tier by sending and loading data on a request-driven basis. In most cases, the presentation layer consists of a Flash file embedded within an HTML page, but it can also be a Flash Standalone Projector running on the desktop, or even a Flash sprite within a Director Projector.

The middle tier sits between the presentation layer and the data source. Its primary role is to separate the presentation tier from the data tier and provide access to the data tier from the Flash Player. The core application logic is also normally implemented in the middle tier. This frees the client to do what it does best—presentation—and frees the server to do what it does best—communicate with databases and manipulate data.

The middle tier resides on the server and can be implemented with various technologies, such as ColdFusion, ASP.NET, and Java. In addition, the middle tier can consist of multiple levels, each adding a layer of abstraction from those immediately above and below it.

In Flash 5, it was common to have a multitiered middle layer, with the uppermost layer serializing and deserializing data to and from the Flash Player, as shown in Figure 1-8.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter was only a brief introduction to the technology. You learned about the basic concepts of Flash Remoting, the benefits of Flash Remoting, and the advantages over traditional methods used in Flash 5. In addition, you saw a typical implementation of a Flash Remoting application and how it works in each server-side language.

Chapter 2 digs deeper into Flash Remoting. It covers installation of the server-side gateway (where necessary) and the authoring components. In addition, the Flash authoring environment is covered as it relates to Flash Remoting. Also, Flash UI components are covered, including additional components from Macromedia.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Being comfortable in a development environment is an important aspect of programming. Flash Remoting requires the utilization of several different technologies. Just getting all the pieces set up properly can be a challenge. This chapter gets you up and running with Flash Remoting. You'll install the components, set up the development environment, and build a simple Flash Remoting example.

Flash Remoting is built into ColdFusion MX (and later) and JRun 4, making these two application servers attractive to begin working with Flash Remoting. ColdFusion Markup Language (CFML) has the added bonus of being relatively easy to learn. Flash Remoting is also available from Macromedia as an add-on for .NET and J2EE servers. Table 2-1 shows the languages that you can use to create server-side Flash Remoting services in each type of installation.

Table 2-1: Flash Remoting official language support
Flash Remoting installation	Languages
ColdFusion MX or later	CFMLServer-Side ActionScriptJavaCFScript
JRun 4	JavaServer-Side ActionScript
J2EE	Java
ASP.NET	VBC#JScript .NetC++Any other ASP.NET language

Table 2-2 lists the open source projects underway that support Flash Remoting using various languages.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Flash Remoting is built into ColdFusion MX (and later) and JRun 4, making these two application servers attractive to begin working with Flash Remoting. ColdFusion Markup Language (CFML) has the added bonus of being relatively easy to learn. Flash Remoting is also available from Macromedia as an add-on for .NET and J2EE servers. Table 2-1 shows the languages that you can use to create server-side Flash Remoting services in each type of installation.

Table 2-1: Flash Remoting official language support
Flash Remoting installation	Languages
ColdFusion MX or later	CFMLServer-Side ActionScriptJavaCFScript
JRun 4	JavaServer-Side ActionScript
J2EE	Java
ASP.NET	VBC#JScript .NetC++Any other ASP.NET language

Table 2-2 lists the open source projects underway that support Flash Remoting using various languages.

Table 2-2: Open source Flash Remoting language support
Project name	Language	URL
AMFPHP

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

I used to work with a guy named Jeff. One day, a new employee—also named Jeff— joined the company. Rather than try to deal with the potential name conflicts, we simply called the new guy "Jim." This worked so well that the boss began using the name Jim on his pay envelope. If someone named Jim were to join the company, however, the naming convention would have to have been reevaluated.

Just like real-life names, service names can have conflicts. It is important that you organize server-side services in such a way that your namespaces don't collide (i.e., conflict) with other namespaces. For example, if you name your service HelloWorld, users attempting to access it might unintentionally access another HelloWorld service of the same name. This is called a namespace collision.

To avoid collisions, service names should always include the directory structure, as used in the package-naming structure of Java, where the package name relates to the domain name and project information of the package. For example, a service from Macromedia for a "Remoting" project might be named com.macromedia.Remoting. The next section describes in more detail how to create a namespace (and the directory structure it implies) that will work for examples in this book. Use this directory for all of your server-side services.

After you've installed ColdFusion, JRun, or another application server and the Flash Remoting gateway adapter, follow these steps to create your directory structure for the samples and the package structure for your remote service files:

Set up a folder on your hard drive, such as c:\frdg_samples\, in which to build the samples used in this book. You can download the finished code from the online Code Depot (cited in the Preface) and unzip them to this directory. This is the directory in which to place the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Flash authoring environment resembles standard software development interfaces familiar to Visual Basic and Delphi programmers. The features specifically advantageous for the Flash Remoting programmer are:

UI components: The built-in Flash UI components allow for drag-and-drop construction of interfaces and easy connection to a data source through Flash Remoting using the DataGlue class. UI components are also extensible, allowing third-party developers to easily add to the core functionality of Flash.
ActionScript code hints and syntax highlighting: The Actions panel (F9) provides lists of methods and properties as you type, as long as you use identifiers consistent with the code-hinting guidelines shown in Table 2-9 later in this chapter. For example, to enable code hinting, include the _mc suffix in the names of movie clip instances.
Object-oriented programming (OOP): OOP standards and conventions drastically reduce the complexity of a Flash Remoting application when used properly. Flash is ideally suited for object-oriented methodologies, which reduce application development time and allow more complex applications to be built.
Property inspector: The Property inspector is common to the Macromedia MX family of tools and is helpful for naming your objects.

The Flash Remoting components, which must be installed separately from Flash, are not visual components like the UI components; they include ActionScript classes for communicating with a server, two new UI panels, and code editor enhancements that make it easier to develop Flash Remoting applications in Flash. You can download the Flash Remoting components from

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

To access a remote service from Flash, your movie must initiate a connection using the NetServices.createGatewayConnection( ) method, which returns a NetConnection object through whose properties, methods, and events you'll manage the connection. You need to know the gateway URL for your Flash Remoting server in order to make a connection. The connection is defined one time for ColdFusion and J2EE servers, even if your movie accesses multiple services via the gateway. However, each ASP.NET service requires its own call to createGatewayConnection( ). In either case, each NetConnection object persists for the entire session. Note that when you create this connection object no call has been made to the server yet.

You'll call methods of the NetConnection object to manage the connection and access the remote service. The two NetConnection methods used most frequently in Flash Remoting applications are setCredentials( ) and getService( ). The setCredentials( ) method is used to authenticate a user.

As of this writing, setCredentials( ) is available for ColdFusion MX and JRun 4 only. It is covered in Chapter 5.

The getService( ) method sets up the call to a remote service by creating a service object, which contains the required information for Flash Remoting to make subsequent calls to methods of that remote service. The getService( ) method's parameters are the same when using any of the service types shown previously in Table 2-8; the service is called by name and Flash makes no assumption about the type of service being called. The syntax for calling the getService( ) method of the NetConnection object looks like this:

myService = myConnection_conn.getService(serviceName[, responderObject]);

where myConnection_conn is a NetConnection object returned by an earlier call to createGatewayConnection( ). The first parameter,

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Now that we have some preliminaries out of the way, it's time to do some Remoting! The steps for a successful Flash Remoting call to a remote service are as follows:

Include the NetServices.as library.
Optionally, initialize variables to hold the URL of the gateway path and the name of the remote service.
Create a connection object that initializes a path to the Flash Remoting gateway.
Create a service object, which will be used to invoke remote services and dispatch results and error events.
Create onResult( ) and/or onStatus( ) callback methods to handle the onResult and onStatus events. These can be contained in a responder object or on the current timeline.
Call the remote service as a method of the service object. The Flash movie continues to execute while waiting for the response, so your code must not assume that the results are returned immediately.
When an onResult or onStatus event is returned, the appropriate callback function is triggered, and the movie reacts as programmed.

The following sections describe the preceding steps in greater detail by going through a slightly more advanced version of the HelloWorld service, called HelloUser. The HelloUser service collects a user-supplied parameter, checks the time on the server, concatenates a string, and passes the whole thing back as a result to the Flash movie. The responder object processes the results of the remote call and displays the string onscreen. This example demonstrates the following concepts not shown in the HelloWorld example:

The setDefaultGateway( ) method of the NetConnection object is utilized.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In this chapter, we set up the Flash authoring environment for Flash Remoting. We enhanced our HelloWorld example from Chapter 1 to create a HelloUser application that demonstrates how to pass a parameter to the server and process some data on the server as well. The example also utilized a custom responder class, which is a preferred way to handle the response from the server. Chapter 3 introduces user interface components and shows how to connect them to remote recordsets.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The most important aspect of building any application—and especially a web application—is to create a comfortable user experience. If the user is bored, frustrated, or uninterested, she will go elsewhere and probably never return. A good Flash movie can hold a user's attention, but the way in which the user interacts with the web application makes the difference between an application that is usable and one that just looks nice.

One of Flash Remoting's prime uses is to create a user interface that does one of several things:

Allow the user to search a remote site or database
Display information to a user
Collect information from a user
Allow interaction with remote databases or programs

Flash components make it easy to create user interfaces, and Flash Remoting adds features that allow easy connection to databases and other programs.

Flash Remoting complements the client-side UI components of the Flash authoring environment. This rigorously pretested set of components, all based on the FUIComponentClass class, brings the familiar user interface elements of HTML to the Flash developer's arsenal. The UI components expose an API that is easy to use and consistent across components.

Prior to Flash MX, you could create movie clips that acted as reusable user-interface controls (a.k.a. Smart Clips), but they were harder to use than Flash's UI components. You can simply drag UI components from the Components panel onto your interface or create new instances programmatically in ActionScript by using the MovieClip.attachMovie( ) method (assuming the Library contains the desired component symbol).

UI components add size to the final Flash movie, but the benefits of using the components far outweigh the downside. In addition, after adding an element of one type to the movie, each additional element of that type does not increase the movie size; your movie is roughly the same size whether you use one ListBox or ten ListBoxes.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Flash Remoting complements the client-side UI components of the Flash authoring environment. This rigorously pretested set of components, all based on the FUIComponentClass class, brings the familiar user interface elements of HTML to the Flash developer's arsenal. The UI components expose an API that is easy to use and consistent across components.

Prior to Flash MX, you could create movie clips that acted as reusable user-interface controls (a.k.a. Smart Clips), but they were harder to use than Flash's UI components. You can simply drag UI components from the Components panel onto your interface or create new instances programmatically in ActionScript by using the MovieClip.attachMovie( ) method (assuming the Library contains the desired component symbol).

UI components add size to the final Flash movie, but the benefits of using the components far outweigh the downside. In addition, after adding an element of one type to the movie, each additional element of that type does not increase the movie size; your movie is roughly the same size whether you use one ListBox or ten ListBoxes.

Flash 2004 and Flash Pro components share a larger common framework (which provides enhanced accessibility, focus management, and so on) than did Flash MX components. The Flash 2004/Pro framework is optimized for movies that include multiple components. If you're including only one or two components and download size is critical, you may prefer to manually implement custom components that are more streamlined.

Table 3-1 lists the UI components that come preinstalled with Flash MX, along with their object type and optional code-hinting suffix. The suffixes are not required, but they enable code hints and code completion when utilized. Data-aware components (components that can be populated by a data provider such as a RecordSet object) are noted. As of this writing, the components included with Flash 2004 and Flash Pro have not been finalized. It is anticipated that Flash 2004 will include a set of components similar to those included with Flash MX. Flash Pro is expected to include all the components available for Flash 2004, plus additional components that support features available in Flash Pro only. This chapter focuses on the components available in Flash MX.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Flash developers can create custom components and other Flash authoring elements, called extensions. The Extension Manager allows developers to package and share their own extensions or install packages developed by others. Many developers have already done this, and you can find extensions all over the Internet, particularly on the Macromedia Exchange, as noted earlier. Components are one type of extension. Flash 2004 and Flash Pro offer a new JavaScript extensibility layer that allows you to customize the Flash authoring tool interface, but here we are referring to ActionScript extensions, which offer enhanced runtime features.

Macromedia has released its own free extensions, including the UI Components Set 2 and the Flash Charting Controls, both outlined in Table 3-2. Each of these useful sets of components is available as a separate download from the Macromedia Exchange at http://www.macromedia.com/exchange, and also on the Studio MX CD-ROM in the \Flash MX\Extending Flash MX folder. Once installed, the UI Components Set 2 and Flash Charting Controls are fully documented under Window → Component Help - UI Set 2 and Window → Component Help - Charts, and within the Reference panel (Window → Reference) in Flash MX and under the Help panel in Flash 2004 and Flash Pro.

Table 3-2: Standard UI Components Set 2 and Charting Controls, showing code hint suffixes and object types
Component	Object type	Code hints suffix
BarChart	FBarChart	_bc

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In October 2002, Macromedia released the first Developer Resource Kits (DRK), containing the UI Components Set 3 and one of the most important Flash extensions to date—the DataGrid component. The DataGrid component is especially important if you are going to be using Flash Remoting. Whereas the standard Flash UI components are included with Flash MX and the UI Components Set 2 are a free download, the DRK is a commercial product available from Macromedia for $99 at:

http://www.macromedia.com/go/drk

The UI components that come with Flash MX provide some useful functionality and interaction with some standard user interface elements. The free UI Components Set 2 adds some more esoteric functionality to the Flash developer's toolbox, such as a calendar control and a ticker. The UI Components Set 3 is available only as part of the DRK and offers more advanced message boxes, tooltips, and loading boxes. None of the UI components in this third set, listed in Table 3-3, are data-aware.

Table 3-3: UI Components Set 3, code hint suffixes, and object types
Component	Object type	Code hints suffix
AdvancedMessageBox	FAdvancedMessageBox	None available
LoadingBox	FLoadingBox

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Text fields are available in the Flash authoring tool from the Tools panel by clicking the Text Tool icon. This allows you to draw a text field on your movie interface. The text that you place in your movie using the Text Tool is an ActionScript object as well—the TextField object.

There are three distinct types of text fields: Static, Dynamic, and Input. A text field's type can be set using the drop-down list in the Property inspector, as shown in Figure 3-2.

Figure 3-2: The Property inspector for a TextField object

To create a static text field, click the Text Tool in the Tools panel and draw an outline on the Stage. A static text field can be used as a label or to display text to the user. However, you can't set an instance name for a static text field, and the field's contents or other properties can't be manipulated via ActionScript. You can enter text in the field during authoring or change its properties through the Property inspector. If you put it in a movie clip, you can alter its appearance indirectly by changing the clip's properties.

Unlike a static text field, you can modify a dynamic text field programmatically. You should use dynamic text fields in your Flash Remoting applications to give you the flexibility to change a field programmatically or alter the labels with localized text.

To control a dynamic text field programmatically, you must give it an instance name using the Property inspector and refer to it by this name from ActionScript. You can activate code hinting for a TextField object by giving it a name ending in _txt.

For example, this sets the text property of a field named myTextField_txt:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

HTML forms are structured elements, consisting of a <FORM> tag surrounding form elements. In Flash, there is no encompassing form tag. The form elements can be text fields, UI components, or other Flash objects and can reside anywhere in the movie. Because Flash is an object-oriented interface, you need only reference the objects by name to access their properties and methods. You can utilize the text property of a TextField object in your Flash Remoting service calls like this:

myService.myMethod(somefield_txt.text);

When you do that, you are essentially posting the contents of somefield_txt to the remote service. This is equivalent to sending a form and the contents of a form field to a server-side page. Because your remote services are expecting the argument, they don't need to process and parse a form field—they need only access the value.

For that reason, building forms in Flash is somewhat of a misnomer. You are not actually building a web form, per se; you are simply creating interface elements that act as collectors of user data and passing this data to your remote services. No form is ever created; no post is ever made to the server. This highlights a key difference between Flash Remoting and working with the LoadVars class (or working with loadVariables( ) in Flash 5).

When working with the LoadVars class, your server-side page has to parse the incoming form data and determine what to do with it. Working with Flash Remoting is almost like working in one environment: you simply pass arguments to remote methods and process the return value. The fact that the methods can be halfway around the world makes Flash Remoting powerful. Flash 2004 handles forms the same way as Flash MX. Flash Pro introduces an alternative to the timeline metaphor—variously called slides, screens, or forms—which should not be confused with submitting data from forms, as discussed here.

The UI components and other ActionScript objects each have their own properties, and some of them have methods to address these properties. Table 3-4 shows several objects that might be used in a Flash Remoting application and how their values can be grabbed through dot notation by accessing a method of the object (or accessing the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Now that we've seen the ease and power of UI components, let's see how interactivity is enhanced using one of the most impressive aspects of Flash Remoting technology: the RecordSet class. Remote method calls commonly return recordsets, which are converted to ActionScript RecordSet objects, to the Flash movie. The RecordSet class has methods that make it easy to work with data returned from a remote method and placed in a RecordSet object. For example, to find the number of records in a RecordSet object, use the getLength( )

Table of Contents