Introducing the Flash Communication Server - Creating an Application
(Page 3 of 4 )
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.
The Flash movie can be hardcoded to connect to a particular instance of a Flash-Com application or it can load the instance’s address at runtime. For example, the movie could load an XML file with connection information or load address information from the HTML page.
For many video-on-demand applications, you can use the prebuilt FLVPlayer, which doesn’t require any Flash authoring, available from:
http://www.peldi.com/blog/FLVPlayer.html
The FLVPlayer’s behavior can be customized to connect to any application instance and includes automatic bandwidth detection and stream selection. A video player is also available as part of the Macromedia Video Kit:
http://www.macromedia.com/software/studio/
flashvideokit
Creating an application to do anything more complex than video-on-demand requires some level of Flash authoring. Unless stated otherwise, when I refer to Flash, I mean the Flash authoring tool, such as Flash MX 2004 or Flash MX Professional 2004 (Flash Pro). If you are not familiar with authoring in Flash, see Flash Out of the Box (O’Reilly), which is an excellent introduction to the authoring tool.
You can create simple communication applications—such as a video conferencing application—using prebuilt components such as the SimpleConnect, PeopleList, and VideoConference components supplied by Macromedia. You can drag the components from Flash’s Components panel to the Stage to construct the user interface. Using Flash’s Properties panel, you can configure the components to work together and supply them with the address of the application instance on a FlashCom Server to connect to. Chapter 2 describes working with Macromedia’s communication components in this way.
For more diverse applications, you must use ActionScript to create or customize components and build unique user interfaces. Chapters 13 through 15 describe how to extend the existing components or roll your own. Existing communication-related ActionScript classes make developing custom components and applications much easier. On the client side, they include the NetConnection, NetStream, Camera, SharedObject, and Microphone classes. Server-Side ActionScript classes include the Application, Client, Stream, and SharedObject classes. We’ll cover these classes and their methods throughout the remainder of the book.
Real-Time Messaging Protocol 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 Mac-romedia’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).
Next: FlashCom Versus Traditional Media Servers >>
More Flash Articles
More By O'Reilly Media
|
 This article is excerpted from the book Programming Flash Communication Server, written by Brian Lesser, Giacomo Guilizzoni, Robert Reinhardt, Joey Lott, and Justin Watkins (O'Reilly, 2005; ISBN: 0596005040). Check it out today at your favorite bookstore. Buy this book now.
|
|
/ 6 
