Programming Flash Communication Server

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

Macromedia Flash has evolved from a way to easily create and distribute lightweight animated graphics on the Web to a rich application platform. Macromedia reported that Flash Player 6 was available on more than 94% of Internet-accessible workstations in Canada, the United States, and Europe as of June 2004. Availability in Asia exceeded 92%. Flash Player 7 penetration ranged from 67% in the U.S. to 81% in Europe. (For the latest statistics, see http://www.macromedia.com/software/player_census/flashplayer/version_penetration.html.) Flash Player 6 and 7 provide some remarkable capabilities to the hundreds of millions of machines on which they are already installed. With the user's consent, a Flash movie can capture real-time audio and video from the machine's microphone or web cam and stream it to Flash Communication Server MX. (Here we use the term movie to refer to .swf files. We use the term video for visual content streamed from the server.) The server can redistribute the streams to other users who have the Flash Player. The resulting real-time communications make it possible to develop a remarkable range of compelling applications. The Flash authoring tool and the Flash Communication Server MX can be used to create:

Highly customized video conferences, team meetings, and web chats with shareable components such as versioned text areas, whiteboards, and instant polls
Video- and data-on-demand applications with rich user interfaces that can include closed captions and skinnable controls
Live event broadcasting with customizable user interaction such as moderated chat and question/answer components
Multiplayer games, simulations, and other applications with the added value of audio and video if required

Flash and the Flash Communication Server MX (FlashCom) provide a rich development environment in which applications that clearly match requirements can be created without an outrageous investment in development time. The Flash Player and FlashCom support a rich set of objects that make sharing real-time audio, video, and data remarkably simple. In addition, Flash provides a set of user interface components such as the DataGrid, Tree, ComboBox, Accordion, and MenuBar, among others. The Flash authoring tool includes a full complement of tools for manually or programmatically generating vector graphics and animations, making it possible to create unique and rich custom user interfaces that can present and update data including audio and video. See the Preface for additional important details about the video delivery options made available by Flash and the FlashCom 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

FlashCom is a server-side application that is installed on a host machine much like a web server; however, FlashCom works very differently than a web server. Instead of accepting many brief connections from browsers requesting a web page or other resource, FlashCom accepts persistent connections from Flash movies running in a Flash Player. Each Flash movie can share data with other Flash movies via the server using Macromedia's proprietary Real-Time Messaging Protocol (RTMP). Unlike the HTTP request/response model used by browsers to communicate with web servers, the Flash Player's RTMP connection to the FlashCom Server is persistent, so no special steps are needed to maintain session information. Once the server accepts a client connection, the connection can be used to exchange audio, video, and ActionScript data until either the client or server disconnects.

The Flash Player may be running within the Standalone Player or within a web browser. The Flash Player (and any movie playing within it) is considered the client. FlashCom cannot initiate a connection to a movie; the connection must be initiated from the Flash Player running on the client. Let's review the architecture briefly so you can understand all the pieces to the puzzle. The client/server architecture for FlashCom applications is shown in Figure 1-1.

Web browsers load Flash movie files (.swf files), load the Flash Player, and pass the .swf file to the Player to execute. The Flash movie provides the user interface and can attempt to connect via the Player to any FlashCom Server. Once connected, the Flash movie can communicate with the server. Furthermore, it can communicate—via the server—with movies playing on other Flash clients. A Flash movie can stream audio and video to the FlashCom Server so that other Flash clients with access to the same server can play recorded streams stored on the server and live streams from other clients.

A live stream is usually one that is published to the server by one client so that other clients can receive it. As the client's data arrives at the server, the server duplicates it and forwards it to each client, where it is seen and heard. In contrast, recorded streams are stored on the server and can be played from any point within the stream, paused, and restarted. It is also possible to stop a recorded stream, seek to any point within it, and begin playing again.

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

Due to the client/server nature of communication applications, the developer ordinarily creates a client-side Flash movie to handle the user interaction and a separate server-side FlashCom application to which it connects. Client-side Flash movies can be written in ActionScript 1.0 or 2.0.

The server-side FlashCom application is written in Server-Side ActionScript (SSAS), which is very similar to the well-known client-side ActionScript. Throughout the book, the code examples identify whether they are client-side or server-side code. To create a FlashCom application, first create a home directory for it on the server. This registers the application with the server and makes it available to movies that attempt to connect to it. Server-Side ActionScript source code files placed in an application's home directory give each application its unique server-side behavior. The Flash authoring tool or integrated development environment (IDE) is used to develop the movie and optionally code the HTML page into which the movie is embedded. During authoring, a Flash movie is saved as a .fla file. When the Flash movie is ready for distribution, it is compiled into a .swf file using Flash's File→ Publish command. After the HTML page and .swf file are posted on a web server, they can be downloaded by a browser, allowing the Flash movie to connect to the application on the FlashCom Server.

Developing a Flash movie almost always involves programming with ActionScript, Flash's scripting language based on the ECMA standard (similar to JavaScript). The book assumes an intermediate familiarity with ActionScript. To learn ActionScript, see ActionScript for Flash MX: The Definitive Guide and Essential ActionScript 2.0, both from O'Reilly. In addition to typical objects, ActionScript supports a special MovieClip datatype. Movie clips are the essential building blocks for Flash animations and are the basis for higher-level components such as the Button, DataGrid, and Tree.

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 Player communicates with FlashCom using Macromedia's proprietary Real-Time Messaging Protocol (RTMP). RTMP uses TCP (transmission control protocol) for transmission of packets between the Flash Player and the server. TCP is a reliable protocol that guarantees delivery of every packet of information. RTMP can transport audio encoded in MP3 and Nellymoser (http://www.nellymoser.com) formats, video encoded in the Flash Video format (FLV), and data encoded using Macromedia's Action Message Format (AMF). AMF provides an efficient way to serialize/deserialize data so that both primitive and complex ActionScript data can be transferred between client and server without needing to manually encode or decode the data. AMF is briefly described in Chapter 11, but for full details, see Flash Remoting: The Definitive Guide (O'Reilly).

Using TCP as the foundation protocol for Flash communications simplifies managing the transfer of audio, video, and ActionScript data flowing between the client and server. However, TCP is a point-to-point protocol, which means each client requires a separate client/server TCP connection; consequently, it cannot broadcast or multicast packets from the server to multiple clients at the network level. If a live audio stream must be sent simultaneously to multiple clients, the server must send duplicate copies of the audio data to each client over discrete connections. Traditional media servers, designed primarily to distribute media streams from server to client, normally provide the option to send the stream using UDP (user datagram protocol) as well as TCP. UDP can be used to multicast or unicast a stream. When multicast is enabled, a single copy of the stream is transmitted, and any client that subscribes to the multicast can receive it. Multicasting has two tremendous advantages: it reduces the load on the server and the bandwidth required to send streams to large numbers of clients. Unfortunately, the vast majority of Internet service providers (ISPs) have disabled multicast on their networks because of security concerns. Consequently, media servers provide a fallback to unicast streaming over UDP. Unicasting means the server must duplicate the stream data and send it in a separate stream to every client. If for some reason the client does not accept the unicast stream, UDP media servers typically fall back to sending duplicate stream data to each client over TCP in much the same way FlashCom does.

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

While RTMP conveniently manages the flow of multiple streams of data across a network, the real power of Flash and FlashCom for developers is realized in the high-level classes that make connecting to the server, sharing information, and streaming audio and video so easy and flexible. I'll briefly review the major classes, which will be explored in more detail and used in examples throughout the remainder of the book.

The NetConnection class connects a client to an application instance on a server. In the simplest case, you can create a connection by invoking NetConnection.connect( ) with the URI of the remote application:

nc = new NetConnection(  );
nc.connect("rtmp://echo.ryerson.ca/campusCameras/connector");

To determine if the connection was established successfully, define an onStatus( ) method on the NetConnection object before invoking connect( ) :

nc = new NetConnection(  );
nc.onStatus = function (info) {
  trace("The connection code is: " + info.code);
};
nc.connect("rtmp://echo.ryerson.ca/campusCameras/connector");

In this example, the RTMP address includes the host (echo.ryerson.ca), the application name (campusCameras), and the instance name (connector). If you've ever developed network applications using other application programming interfaces, you'll likely agree that creating a network connection between Flash and FlashCom is ridiculously easy. Chapter 3 goes into greater detail on the NetConnection class and how to use NetConnection objects.

Once you establish a connection using a NetConnection object in the client, you can use it to send or receive a stream containing audio and/or video. Suppose you know that a recorded Flash video file named Ryerson_High_Speed.flv is available in the instance's public directory. You can attach the video stream to a video object, here named

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 and the Flash Communication Server often must work with other existing applications and resources. For example, users may have to log in against an existing directory service or database before being allowed to chat or view streams. Database systems can be used to store large amounts of information that FlashCom cannot easily manage, such as millions of records that represent the location of video messages in a video email system. Each record might contain the email text and the location of the recorded video message within a FlashCom application.

Both the Flash Player and FlashCom can interact with web application servers and, through them, database and directory servers. The Flash client can call any server-side script available on a web server, send and receive XML data, access web services, and use the Flash Remoting gateway to more efficiently access application servers. In contrast, the Flash Communication Server (as of the latest version, 1.5.2) supports only Flash Remoting to connect to other servers. It cannot directly consume web services, send or receive XML, or call a CGI script, which often complicates designing applications that need to access a database or other service already available via a web server. However, Flash Remoting is a powerful and efficient technology that can be used with J2EE, ColdFusion, and .NET servers to provide access to databases or other services. Macromedia sells the Flash Remoting gateway separately for J2EE and .NET servers and bundles it with ColdFusion. There are also open source implementations of Flash Remoting for Perl, PHP, and Java. See Chapter 11 for more details on Remoting, and see http://opensource.org for information on open source code.

Flash Remoting is a request/response technology that allows scripts in the Flash client or FlashCom to call remote methods on an application server. It uses HTTP to send and receive data in the AMF. Those remote methods can retrieve information from a database, directory server, or web server and return the information to FlashCom. From a developer's point of view, Flash Remoting is easy to work with because complex ActionScript data is serialized and deserialized automatically. Flash Remoting can be used with or without FlashCom. The point is that Flash Remoting is flexible enough that it allows FlashCom to communicate effectively despite FlashCom's lack of direct support for XML or server-side script access.

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

Some corporate firewalls and proxy servers with restrictive access rules make it impossible to establish a persistent TCP/RTMP connection to a FlashCom Server. Some corporate IT staffs may open access to remote FlashCom Servers, but others will not. When corporate web access is permitted but TCP/RTMP connections are not allowed, FlashCom provides a tunneling feature that allows Flash and FlashCom to send and receive RTMP over HTTP. When tunneling is employed, the Flash Player works with the user's browser to poll the communication server instead of establishing a direct Player-to-server TCP connection. When RTMP is tunneled, it is known as RTMPT. As of this writing, neither the Flash Player nor FlashCom directly supports SSL. However, encryption is an option when using tunneling, because browsers support SSL and an SSL proxy can be used with the server. For more information, see the article Tunneling Flash Communications Through Firewalls and Proxy Servers at:

http://www.macromedia.com/devnet/mx/flashcom/articles/firewalls_proxy.html

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

A free development edition of the Flash Communication Server is available from Macromedia. You can find more information on downloading it along with other licensing options at Macromedia's web site:

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

To install FlashCom:

Follow the link from the preceding URL to download the free developer edition or go directly to:

http://www.macromedia.com/cfusion/tdrc/index.cfm?product=flashcom
Once you install FlashCom, you should download the most recent updater from http://www.macromedia.com/support/flashcom/downloads_updaters.html and install it. (Updaters are not normally added to the installation files of the most recent release, so if an updater is available for the most recent release, you should download and install it.)
Finally, download the most recent Flash communication components and run the installation program to install them in the Flash authoring environment. Separate Windows or Macintosh component updates are also available at:

http://www.macromedia.com/support/flashcom/downloads_updaters.html

FlashCom runs on Windows Server 2003, Windows Server 2000, Windows NT Server SP6 or later, and RedHat Linux. The complete system requirements and supported servers are listed at:

http://www.macromedia.com/software/flashcom/productinfo/systemreqs

Detailed documentation about the server including installation instructions is available from Macromedia 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

I'd like to dive in and take you through building a very simple video conference application. The application is designed to demonstrate many of the different things described in this chapter, such as publishing and playing streams and updating and responding to changes in a shared object. If you don't understand all the code as I walk through it, don't worry. The idea is to provide a quick tour to building a communication application. The rest of the book explains everything in much greater detail. Although a premade video chat application already exists, this is good exposure to the concepts and operations you'll need when you build your own applications.

Creating the helloVideo application on the server requires you find the applications directory and add a subdirectory named helloVideo. After the default installation on my system, the applications directory is located at:

C:\Program Files\Macromedia\Flash Communication Server MX\applications

Once you create the helloVideo subdirectory, you have created a FlashCom application. Now you need to provide the application with its unique server-side behavior. Create a plain text file named main.asc and save it into the helloVideo directory. You can use any plain text editor such as the one included with Flash MX Professional 2004 or Dreamweaver MX 2004. Example 1-1 shows the source code you should add to the main.asc file.

Example 1-1. The main.asc file for the helloVideo application

idPool = ["guest_1", "guest_2", "guest_3", "guest_4"];

application.onAppStart = function ( ) {
  users_so = SharedObject.get("users");
};

application.onConnect = function (client, name) {
  if (idPool.length <= 0) {
    application.rejectConnection(client, {msg:"Too many users."});
  }
  client.id = idPool.pop( );
  application.acceptConnection(client);
  client.call("setID", null, client.id);
  users_so.setProperty(client.id, name);
};

application.onDisconnect = function (client) {
  idPool.push(client.id);
  users_so.setProperty(client.id, null);
};

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

While writing this book, I met online with the other authors to discuss our project. I used some of the sample applications I wrote for the book and another Macromedia application built on top of Flash and FlashCom: Breeze Live. One of the earliest conferences I had was with Robert Reinhardt. I was at home in Toronto, on eastern standard time, and he was in Los Angeles on Pacific time. It was dark in Toronto and the sun was about to start setting in L.A. Aside from the immediacy of our conversation—something more akin to being in the same room than being on the phone or using text messaging—there was something compelling about seeing the light gradually change on the other side of the continent as we spoke. In later conferences with Giacomo Guilizzoni, I was impressed with how helpful it was to be able to share code and make notes that we could both see and edit while we discussed what parts of this book each of us should work on. Communication applications that include live video, audio, and data make collaboration at a distance more immediate and effective. Flash and FlashCom together provide a platform that can be used to build a wide range of compelling communication applications. Whether you need to build a shared simulation to enhance an online course or a simple video conference, text chat, or video-on-demand application, you'll find a rich toolbox of classes and components to create it described in detail in the chapters that follow.

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

Macromedia introduced components with the release of Flash MX. Components allow a Flash designer or developer to quickly add interface elements or interactive behaviors to a Flash movie. The default installation of Flash MX 2004 enables the UI components, which are basic GUI enhancements, such as scrollbars, list boxes, and push buttons. Macromedia has continued to release additional component packages for Flash MX 2004, especially those to complement Macromedia MX server products such as Flash Remoting MX and Flash Communication Server MX. In this chapter, you will learn about the communication components and how the essential components can be used to create basic FlashCom applications.

Before you begin this chapter, make sure you have downloaded and installed the latest communication components.

If using Flash MX, obtain the communication components here:

http://www.macromedia.com/software/flashcom/download/components

If using Flash MX 2004 or Flash MX Pro 2004, download the updated components here:

http://www.macromedia.com/support/flashcom/downloads_updaters.html

You don't have to rely solely on Macromedia's components. You can download third-party components from the Flash Communication Server category of the Exchange (http://www.macromedia.com/cfusion/exchange/) and install them with the Macromedia Extension Manager. You can also create your own custom components as described in Chapter 13.

The original communication components released for Flash MX featured the Flash MX UI Components with new skins, decorating push buttons with rounded bluish rectangles. The communication components for Flash MX 2004 still use the older Flash MX UI Components, except that these versions use the original gray themed skins. The newer v2 UI components of Flash MX 2004 are not used by either version of the communication components. While the look-and-feel of the older components is not as refreshing as the newer ones, keep in mind that the older UI components are compatible with all minor releases of Flash Player 6, while the new UI components are compatible only with the last releases of Flash Player 6 and higher.

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

There are 16 components in the communication components set. Like all Macromedia components, each contains several built-in ActionScript methods and properties, and you can change the look-and-feel (or skin) of each component to suit your particular tastes.

Some developers report difficulty creating custom skins (it may involve writing extra drawing code, changing hard-to-find assets, or dealing with components that implement the skinning API only partially). Search the FlashCoders archive or Wiki at http://chattyfig.figleaf.com for some of the discussion.

Chafic Kazoun wrote the following guide to skinning the Flash MX 2004 Components:

http://www.macromedia.com/devnet/mx/flash/articles/skinning_2004_print.html

You can use the communication components to quickly set up a proof-of-concept FlashCom application that connects one or more users to an application instance and enables live real-time interactivity between the participants. Many of the components can publish audio/video streams to a FlashCom application, while others focus on text or data sharing.

After you have installed the communication components, you can view the components in Flash:

If you just installed the components and Flash was running, quit and restart Flash.
Open the Components panel by choosing Window→ Development Panels→ Components.
In the Components panel, expand the Communication Components node as shown in Figure 2-1.

Figure 2-1: The communication components in the Components panel

You will likely find that most of these components have limited appeal for final production-quality Flash movies that you'll make available on a public web site.

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 discussed the methods common to all components, let's look at the specifics of the individual components (in alphabetical order). You may want to take a quick peak at the SimpleConnect component discussed later in the chapter, as many other components rely on the connection it establishes. See Section 2.6 at the end of the chapter for how to notify other components of a connection without using the SimpleConnect component.

Here are some guidelines to help you understand the following sections on the individual components:

The corresponding client-side ActionScript class for a FlashCom communication component has a name of the form FCC omponentName Class; for example, the class name of the AudioConference component is FCAudioConferenceClass.
Most of the communication components have parameters that can be configured in the Properties panel or the Component Inspector panel. If there are parameters that are configurable through the UI for a component, we cover them in the description of each component. All component parameters can also be configured using ActionScript properties of the component as noted. For example, the LatencyThreshold parameter of the ConnectionLight component is configurable using the component's threshold property. Some component parameters are configurable only via ActionScript, such as the username property of the Chat component. It is up to the component developer to determine which properties of a component are exposed in the Properties panel or the Component Inspector panel. The communication components' parameters can be exposed in the Component Definition dialog box (available by right-clicking or Cmd-clicking the component symbol in the Library). For any component written in ActionScript 2.0 (AS 2.0), such as the Flash MX 2004 UI Components, parameters can also be exposed by defining inspectable properties in its

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 you have a basic overview of the communication components, let's see how to use them to create an application. We'll build a Flash movie that connects to a FlashCom application using the SimpleConnect and ConnectionLight components. The SimpleConnect component will specify the URI of the FlashCom application, and the ConnectionLight instance will display the statistics of the connection.

Make sure you have installed the latest communication components for Flash MX or Flash MX 2004, as cited at the beginning of the chapter, before you begin this exercise.

First, set up the basic_app application as follows:

On the computer running FlashCom Server, browse to the applications folder. Create a new folder named basic_app at this location.
In Flash Pro or your preferred text editor, create a new ActionScript Communication document. Add the following code to the document:
```
load("components.asc");
```
This line of code instructs the FlashCom application to load the components.asc document from its scriptlib folder, which in turn loads the .asc files for each communication component.
Save the text document as main.asc in the basic_app folder you created in Step 1.

Your FlashCom application is now prepared to use communication components.

Now that the server-side .asc code is complete, we have to create the client (.swf) movie:

Create a new Flash document (File→ New). Save this document as component_connection.fla.
Rename Layer 1 to connect_mc. This layer will be used to hold an instance of the SimpleConnect component.

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 you know how to connect to a FlashCom application using the SimpleConnect and ConnectionLight components, you can proceed to add features to the application. In the following steps, you will learn how to add the PeopleList, Chat, and UserColor components to the basic_app application:

Open the component_connection.fla you created in the last section. Resave this document as component_chat.fla.
Create a new layer named list_mc. On frame 1 of this layer, drag an instance of the PeopleList component from the Components panel to the Stage. Name the instance list_mc using the Properties panel. Also, place this component near the lower-left edge of the Stage, as shown in Figure 2-20.

Figure 2-20: The list_mc instance
Create another layer named chat_mc. On frame 1 of this layer, drag an instance of the Chat component to the Stage. Name the instance chat_mc using the Properties panel. Place this component to the right of the list_mc instance, as shown in Figure 2-21.

Figure 2-21: The chat_mc instance
Create another layer named userColor_mc. On frame 1 of this layer, drag an instance of the UserColor component to the Stage. Name the instance userColor_mc using the Properties panel. Place this instance below the SimpleConnect and ConnectionLight instances near the upper left of the Stage, as show in Figure 2-22.

Figure 2-22: The userColor_mc instance

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 add audio/video streaming capabilities to the chat room, you can add the AudioConference, AVPresence, or VideoConference component to the Flash document you created in the last section. In the following steps, you will add two instances of the AVPresence component and an instance of the SetBandwidth component to the movie:

Open the component_chat.fla from the last section. Resave this document as component_avchat.fla.
Create two new layers, named av_1_mc and av_2_mc.
On frame 1 of the av_1_mc layer, drag an instance of the AVPresence component from the Components panel to the Stage. Place the instance to the right of the ConnectionLight instance and above the Chat instance. In the Properties panel, name this instance av_1_mc.
Repeat the previous step for another instance of the AVPresence component. Place the new instance on frame 1 of the av_2_mc layer, positioned to the right of the av_1_mc instance. Name the new instance av_2_mc.
Create a new layer named bandwidth_mc. On frame 1 of this layer, drag an instance of the SetBandwidth component to the Stage. Place the instance below the userColor_mc instance. Name the new instance bandwidth_mc using the Properties panel. Your Stage should now resemble Figure 2-24.

Figure 2-24: The new communication components added to the movie's Stage
Select the connect_mc instance on the Stage, and double-click its Communication Components parameter in the Parameters tab of the Properties panel. In the Values list, add the instance names of the three additional communication components—av_1_mc, av_2_mc

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

If you are building your own custom FlashCom applications and Flash client movies, you'll likely have your own login systems and user interface elements, complete with username and password fields. In such cases, you'll need to connect communication components to your FlashCom applications without the use of the SimpleConnect component. In this last section, you will learn how to enable the ConnectionLight component for an application by using your own custom client-side ActionScript code.

First, create a new server-side application. On the computer running the FlashCom Server, browse to the applications folder and create a new folder named test_app at this location. In the next section, you will create a client-side NetConnection object that connects to this application space.

Create a new Flash document (File→ New), and save the document as no_simpleconnect.fla.
Rename Layer 1 to light_mc. On frame 1 of this layer, drag an instance of the ConnectionLight component from the Components panel to the Stage. Name the instance light_mc using the Properties panel.
Create a new layer, and name it actions. Place this layer above the light_mc layer.

Select the first frame of the actions layer, and open the Actions panel (F9). Add the following code:

app_nc = new NetConnection(  );
app_nc.onStatus = function (info) {
  trace("app_nc: info.code = " + info.code);
  if (this.initLight == null) {
    light_mc.connect(this);
    this.initLight = true;
  }
};
app_nc.connect("rtmp:/test_app");

Here, you create a new NetConnection object that invokes connect( ) on light_mc when the onStatus( ) event handler is invoked. An internal property named initLight is used to track whether 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

We're in only the second chapter of the book, and you've already come a long way. This chapter showed how the FlashCom communication components encapsulate commonly needed features such as chat, video recording and playback, bandwidth control, user configuration, and more. These components implement much of a FlashCom application's plumbing so you can create basic applications quickly and then enhance them with additional features as needed. We already saw how to build a simple chat room and add audio and video to it.

Now that you have a basic understanding of creating a simple FlashCom application, we'll explore the technical issues in more detail. In the next chapter, we cover creating and managing connections. In subsequent chapters, you'll master additional topics such as applications and instances, media and data streams, and the Camera and Microphone classes. You've already seen a glimpse of FlashCom's power but the journey is just beginning.

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

Before a Flash movie can exchange audio, video, and other data with a FlashCom Server application, it must request a network connection to the server. If an application instance on the server accepts the connection request, a TCP connection is made available to both the movie and application instance to use for ongoing communications. We saw in the preceding chapter that the SimpleConnect component can create a connection. This chapter covers connections in more depth, including how to write custom code to handle various changes in the connection status as well as different error types.

A network connection can be managed within a Flash movie using a NetConnection object. This object's methods are used to request, close, and monitor the status of a network connection. The SharedObject and NetStream classes, as well as Macromedia's communication components, all depend on access to a NetConnection object in order to communicate with the FlashCom Server.

NetConnection objects are created by calling the NetConnection( ) constructor function:

lobby_nc = new NetConnection(  );

In this example, the lobby_nc variable stores a NetConnection object, which can be used to attempt to connect to an application instance:

if (lobby_nc.connect("rtmp:/testLobby", userName, password)) {
  trace("Attempting connection...");
}
else {
  trace("Can't attempt connection. Is the URI correct?");
}

In this example, the URI rtmp:/testLobby is the address of an instance of an application named testLobby that resides on the server from which the movie was downloaded. The connect( ) method is always passed the URI of the application instance to which to connect, followed by any number of optional parameters. In this example, a username and password are supplied after the URI. The connect( ) method returns false if it detects a malformed URI; otherwise, it returns

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

NetConnection objects are created by calling the NetConnection( ) constructor function:

lobby_nc = new NetConnection(  );

In this example, the lobby_nc variable stores a NetConnection object, which can be used to attempt to connect to an application instance:

if (lobby_nc.connect("rtmp:/testLobby", userName, password)) {
  trace("Attempting connection...");
}
else {
  trace("Can't attempt connection. Is the URI correct?");
}

In this example, the URI rtmp:/testLobby is the address of an instance of an application named testLobby that resides on the server from which the movie was downloaded. The connect( ) method is always passed the URI of the application instance to which to connect, followed by any number of optional parameters. In this example, a username and password are supplied after the URI. The connect( ) method returns false if it detects a malformed URI; otherwise, it returns true, and Flash attempts to connect to the server.

Not all malformed URIs are caught by the connect( ) method. You must always make sure the protocol is either rtmp or rtmpt followed by a colon; otherwise, the connect( ) method may return true and then fail.

The URI can be an absolute URI that includes a hostname or a relative URI that does not. After the connect( ) method is called, the URI passed into it is available as the uri property of the NetConnection object.

An absolute URI is a string that includes protocol, host, optional port, application name, and optional instance name segments. The format of an absolute URI is:

rtmp[t]://host[:port]/applicationName[/instanceName]

The parts of the URI in square brackets are optional. An absolute URI contains all the information needed to identify an application instance to which to connect. The following sections describe all the parts of an absolute URI.

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

After a successful connection is made, it can be broken by various occurrences. A well-scripted Flash movie monitors the network status and takes appropriate action as changes occur. This is easily done inside your NetConnection.onStatus( ) handler, which is notified whenever the connection status changes. When a connection is first established, the objects and components that rely on it can begin using it. When a connection is closed, these objects may have to be disabled or disposed of. It is especially important that the user doesn't experience a sudden and unexplained loss of functionality when a network connection is dropped by the server or lost because of a network problem.

A common—and sometimes difficult to debug—problem occurs when scripts define the onStatus( ) handler after calling the connect( ) method:

nc = new NetConnection(  );
nc.connect(  ); // WRONG: do this after onStatus is defined!
nc.onStatus = function (info) {
  trace("info.code: " + info.code);
};

If connect( ) is called prematurely, the network connection may be established or the connection rejected before the onStatus( ) handler has been defined. The result is that the messages representing those events are never returned to the handler. The onStatus( ) method must always be defined before the connect( ) call is made. The preceding example should be rewritten as:

nc = new NetConnection(  );
nc.onStatus = function (info) {
  trace("info.code: " + info.code);
};
nc.connect( );

For the most part, when a connection is closed, the info object passed to the onStatus( ) method will have a level value of "status" and a code value of "NetConnection.Connect.Closed". This will happen if the network goes down, the server disconnects the client, the server stops, or the connection is closed using NetConnection.close( ). It is also possible that the level value will be "error" and the code value "NetConnection.Connect.AppShutdown". The following sections discuss how to deal with various connection status changes.

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

Often a Flash movie must connect to more than one application instance. A familiar example is when Flash must first connect to a lobby so the user can select a chat room to visit. In this case, the lobby may be one application and the chat rooms may be implemented by another application. The lobby connection can be closed and then a new NetConnection object, with a different onStatus( ) method, can be created to connect to the chat application. Instead of creating a new NetConnection object, the Flash movie can reuse an existing one. In theory, you can disconnect from one application and connect to another by calling the connect( ) method with a new target URI. When this happens, the old connection is closed and a new one is attempted. However, two other things should normally happen. First, before a connection is closed, you should perform any required cleanup, such as closing objects and components that depend on the connection. Second, you must perform any preparatory work—at minimum you'll usually put in place a different onStatus( ) handler—before connecting to the next application.

To follow through with the previous example, suppose an additional application, named testChat, is available and that once the user is in the lobby he can click a button to visit a testChat instance named room1. In this case, the main timeline of the movie would require separate Login, Lobby, and ChatRoom frames as illustrated in Figure 3-2.

Figure 3-2: The timeline with Login, Lobby, and ChatRoom states

The Chat button would be placed in the Lobby frames, and a Lobby button would be placed within the ChatRoom frames. Example 3-4 shows the onChat( ) function that would be called when the Chat button is clicked.

Example 3-4. Connecting from the lobby to a chat room

function doChat (btn) {
  // Don't process the next close message.
  lobbyChat_nc.handleCloseEvents = false;
  // Close the connection to the lobby.
  lobbyChat_nc.close( );

  // Set 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

Macromedia recommends against making multiple connections from a single Flash movie to a FlashCom Server or Servers at the same time. First of all, each server can handle only so many simultaneous connections and the data transfer overhead that goes with them. Furthermore, FlashCom is licensed by the number of simultaneous connections. Therefore, whenever possible, avoid designing communication applications that require multiple simultaneous connections. However, a Flash movie can connect simultaneously to different applications or different instances of the same application; it can also connect multiple times to the same application instance, if necessary. This is an especially useful feature when testing applications and in developi

Table of Contents