Developing Media Applications
Trademarks 1 Step RoboPDF, ActiveEdit, ActiveTest, Authorware, Blue Sky Software, Blue Sky, Breeze, Breezo, Captivate, Central, ColdFusion, Contribute, Database Explorer, Director, Dreamweaver, Fireworks, Flash, FlashCast, FlashHelp, Flash Lite, FlashPaper, Flash Video Encoder, Flex, Flex Builder, Fontographer, FreeHand, Generator, HomeSite, JRun, MacRecorder, Macromedia, MXML, RoboEngine, RoboHelp, RoboInfo, RoboPDF, Roundtrip, Roundtrip HTML, Shockwave, SoundEdit, Studio MX, UltraDev, and WebHelp are eith
Contents About This Manual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Intended audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 About the Flash Media Server documentation . . . . . . . . . . . . . . . . . . . . . 8 Support for learning about Flash Media Server . . . . . . . . . . . . . . . . . . 9 Typographical conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 3: Using Media Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 About Flash Media Server classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 About Client-side classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 About Server-side classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 About client-server communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Understanding shared objects . . . .
Chapter 5: Debugging and Monitoring Applications . . . . . . . . . 65 Using the management console to debug and monitor application . 65 Connecting the management console to a server . . . . . . . . . . . . . . 66 About the View Applications panel . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 About the Live Log panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 About the Clients panel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About This Manual Welcome to Macromedia Flash Media Server 2—a powerful server platform for creating rich media applications in Macromedia Flash and for streaming audio and video to Flash clients. Flash Media Server (FMS) can enable two or more people to participate in a real-time conversation using text, audio, or video. For example, you can use FMS for meetings, online community interaction, customer support, sales support, or training.
About the Flash Media Server documentation The Flash Media Server documentation is designed to be used with the Flash documentation, namely Using Flash and the ActionScript 2.0 Language Reference Guide. All Flash Media Server documents are available in PDF format (viewable and printable with Adobe Acrobat Reader) on the Flash Media Server CD and on the Macromedia web site and as Flash Help in the Macromedia Flash application (select Help > Flash Help).
Support for learning about Flash Media Server You may want to explore these other sources of support for learning about Flash Media Server: ■ The Flash Media Server Support Center provides TechNotes and up-to-date information about Flash Media Server. ■ The Flash Media Server Developer Center site provides tips and samples for creating Flash Media Server applications. ■ The Flash Media Server Online Forum provides a place for you to chat with other Flash Media Server users.
About This Manual
1 CHAPTER 1 Getting Started This chapter describes initial steps you need to take before you begin developing applications with Macromedia Flash Media Server 2. It describes how to set up your development environment, how to deploy your applications, and how to create a simple application to connect to the server. Installation and system requirements For instructions on how to install Flash Media Server and for information on system requirements, see Installing Flash Media Server.
Flash Player Make sure that you are using the latest version of Flash Player. You can download Flash Player from the Macromedia website at www.macromedia.com/go/ getflashplayer. NO TE If you are running Flash Media Server on Linux, you’ll need a Windows or Macintosh computer with Flash to create your media applications, and you’ll need to install the authoring extensions on your authoring computer. You’ll also want to install Flash Player on your UNIX server computer to use the administration tools.
Creating a development environment This section explains what you need to know before you create Flash Media Server applications. Make sure the server is running To publish and test your applications, Flash Media Server must be running. For more information, see “Starting the service” on page 19. Specifying the server URI Use the Flash authoring environment on the same computer that is running the Flash Media Server.
Acknowledging the user’s right to privacy Before you record or broadcast anyone’s image or voice, it’s important to inform that person of your intention and to gain their consent or agreement. Monitoring running applications If you have server administration permissions, you can view details about an application while you are testing it, such as log messages it is generating, values of shared objects, and so on. To do so, open the management console and connect to the Flash Media Server.
5. Publish the SWF file for your application in a directory accessible to your clients but that Flash Media Server does not use. For example, you could put your SWF file in the web root directory that will serve your application to your clients, or you could e-mail the SWF file to your clients and store the SWF file in some other directory. Depending on your application, additional steps are required; however, these steps are necessary for all applications, regardless of their functionality.
For organizational purposes during your development work, it might be convenient to store all of our client and server application files (FLA, SWF, HTML, or ASC) in one subdirectory. When you deploy your application, you can place your SWF and HTML files in any location. However, the registered application directory must remain on the Flash Media Server server, along with any ASC, FSO, and FLV files that the application uses.
About application instances Applications are run by creating application instances. When a client connects to an application, the client is actually connected to an application instance. For example, a client connects to an application named chat_app, as the following example shows: nc.connect(“rtmp://myDomain.com/chat_app”); In this example, the client is actually connected to the default instance of the application, named _defInst_, because no instance is specified.
second_nc.connect("myserver.mydomain.com/support/session2"); second_so = SharedObject.getRemote("CustomerInfo", second_nc.URI, false); second_so.connect(second_nc.URI); Instance name room_01 is frequently used, but you can use any string for an instance name that makes sense in your application. You can configure several settings related to application instances. In the Application.xml file, you can configure the maximum idle time before the server unloads an instance. In the Vhost.
FLV and IDX files Recorded streams and their associated index files. When the server generates streams, it also generates a streams directory in the registered application directory and stores FLV and IDX files in a subdirectory specific to the application instance (for example, /applications/chat_app/streams/instance2). SOL, SOR, and FSO files Shared object files.
Opening a connection to the server Open a new file in the Flash authoring environment, and then add the client-side ActionScript commands to connect to the server. To connect to Flash Media Server: 1. In a new Flash application, begin opening a connection by issuing the following command: my_nc = new NetConnection(); 2. Follow this command with a connect command: my_nc.connect(targetURI); In this basic syntax for NetConnection.
CHAPTER 2 2 Flash Media Server Architecture The Macromedia Flash Media Server 2 platform is made up of two parts: the server and Macromedia Flash Player. Applications built on this platform consist of a client Macromedia Flash application (SWF file) that is run by Flash Player, and a server component that communicates with the client. The server component consists, minimally, of an application folder you’ve created on the server that is running Flash Media Server.
Understanding the Flash Media Server architecture The server and the Flash client application communicate over a persistent connection using Real-Time Message Protocol (RTMP). In a typical scenario, a web server delivers the Flash client to Flash Player over HTTP. The Flash client then uses RTMP to establish a persistent connection to Flash Media Server, allowing for an uninterrupted data stream to flow between client and server.
Multiple users (Flash clients) can connect to the same application running on Flash Media Server, which acts as a communication channel between connected users. Client 1 Client 2 Server Flash Media Server provides a channel of communication for clients. NO T E You can also create secure RTMPS connections. For more information, see NetConnection.connect() in the client-side and server-side ActionScript Language References.
Recorded streams are saved in the Flash Video (FLV) format. Recorded streams can contain data messages, as well as video. You can also create FLV files from existing digital video or audio files by using third-party video encoding utilities, like On2 or Sorenson Squeeze, or export them from Flash. In this way you can use the Flash Media Server to stream prerecorded content.
Understanding shared objects The two basic types of shared objects you can use when you create media applications are local and remote. You can think of local shared objects as “Flash cookies”: they let you save data to a user’s computer for off-line access, or for saving preferences. Local shared objects are a feature of Flash Player and do not require Flash Media Server.
About connecting to external data sources In addition to the communication models that streams and shared objects provide, Flash Media Server can also interact with external data sources such as web services and relational databases, or even other Flash Media Server applications. For example, you might write server-side ActionScript to connect to a web service (use the WebService class) or ColdFusion application to retrieve a list of names and phone numbers.
Workflow for creating and deploying applications You use the Flash authoring tool to create your application’s client component, which runs in Flash Player. The Flash SWF file provides the application’s user interface, and also contains ActionScript for connecting to, and managing interactions with, Flash Media Server. For more information on client-side Media ActionScript, see the Client-Side ActionScript Language Reference for Flash Media Server 2.
The server files, including any ASC files, recorded stream (FLV) files and other server-side resource files, are published to the registered application directory you’ve defined on the server. SWF FILE . swf Flash logic ActionScript . swf . swf HTML FILE . ht ml Web server directory HTML HTML wrapper ASC FILE . asc . asc Server logic Server-side ActionScript .
If you’re an administrator, you’ll use the management console to configure Flash Media Server, set up system security, monitor usage, start and stop the server, and add users. For more information on administration tasks for Flash Media Server, see Managing Flash Media Server.
Understanding connection flow The client connects to the server, and the server calls onAppStart when the application instance is loaded (if the application is already running, onAppStart is not called). Next, the server-side onConnect handler is invoked with a newly created Client object. The logic in this method determines whether to accept or reject the connection. On the client side, the onStatus handler is called to report whether the connection was accepted or rejected.
Invoking remote methods After a successful connection, the client can invoke remote methods that the server component defines; the server application can also remotely invoke ActionScript methods defined in the Flash client application. Invoking server methods from the client Each Flash application that connects to a server application is represented by a Client object, which is an instance of the server-side Client class.
The following table lists Flash Media Server Client Status Messages: Code Level Meaning NetStream.Clear.Success Status A recorded stream was deleted successfully. NetStream.Clear.Failed Error A recorded stream failed to delete. NetStream.Publish.Start Status An attempt to publish was successful. NetStream.Publish.BadName Error An attempt was made to publish a stream that is already being published by someone else. NetStream.Failed Error An attempt to use a Stream method failed. NetStream.
For more information on invoking server methods remotely, see the Client."commandName" entry in the Server-Side ActionScript Language Reference. Invoking client methods from the server The process for invoking client-defined methods from the server is similar to the reverse case. On the client, you can attach a user-defined method to the NetConnection object used to connect to the server. The server can then use the Client.call() method to call that method remotely.
Code Level Meaning NetStream.Record.NoAccess Error An attempt was made to record a read-only stream. NetStream.Record.Stop Status Recording was stopped. NetStream.Record.Failed Error An attempt to record a stream failed. NetStream.Play.Start Status Play was started. NetStream.Play.StreamNotFound Error An attempt was made to play a stream that does not exist. NetStream.Play.Stop Status Play was stopped. NetStream.Play.Failed Error An attempt to play back a stream failed. NetStream.
After the client is connected to the shared object, the server sends out a synchronization message for the shared object, which is handled by the SharedObject.onSync event handler defined on the client. When the client, the server, or any other movie instance makes a change to the shared object, the server again sends out a synchronization message for the shared object. Each synchronization message contains a code that specifies the nature of the change that occurred to the shared object.
Flash Media Server Architecture
3 CHAPTER 3 Using Media Classes Macromedia Flash Media Server provides two application program interfaces (APIs): a clientside API and a server-side API. This chapter explains the client-side classes, the server-side classes, and how objects created from these classes are paired during communication. Shared objects are also discussed, as they store information about the application and users for sharing between users, application instances, and applications.
Camera class The client-side Camera class lets you capture video from a video camera attached to any computer running Macromedia Flash Player. When used with Flash Media Server, this class lets you transmit, display, and optionally record the video being captured. With these capabilities, you can develop media applications such as videoconferencing, instant messaging with video, and so on.
To place a Video object on the Stage from within Flash: 1. In Flash, select Window > Library to display the Library panel if it isn’t open. 2. Add an embedded Video object to the library by clicking the Options menu at the upper right of the Library panel and selecting New Video. 3. Drag the Video object to the Stage and use the Property inspector to give it a unique name. About Server-side classes These classes are used only in server-side ActionScript.
You can use Macromedia Flash Remoting with the Flash Media Server to communicate with application servers such as Macromedia ColdFusion, .NET, and J2EE servers. For more information, see the Flash Remoting information on the Macromedia website at www.macromedia.com/go/flashremoting. SharedObject class Server-side shared objects let you communicate with client-side shared objects and with objects on other Flash Media Servers.
In the following table, the client-side calls on the left invoke the server-side calls on the right. Client-side call Server-side call my_nc.connect application.onConnect my_nc.close application.onDisconnect my_nc.call("doThing", myCallbackFcn, 1, "foo") my_client.doThing(1, "foo") my_so.send("doThing", 1, "foo") my_server_so.doThing(1, "foo") In the following table, the server-side calls on the left invoke the client-side calls on the right. Server-side call Client-side call my_client.
About remote shared objects Using client-side ActionScript, you can create and reference shared objects that are available to other Flash Media Server application instances running on the same or different clients. Like local shared objects, these objects can persist on the local computer. However, they can also persist on the server, so that any user who connects to the shared object has access to the same information.
For more information on the Application class, see the Application class entry in the Server-Side ActionScript Language Reference. Using the application.onConnect handler The application.onConnect event handler is invoked on the server when a client calls the NetConnection.connect() method.
Also, if you want to use the call() method on the Client object that is connecting, make sure you call application.acceptConnection() and know that the client is connected before issuing any additional commands. The following code sets up this sequence of actions: application.onConnect = function(clientObj,name,passwd) { // First accept the connection application.acceptConnection(clientObj); // After client is registered with the application instance // you can use "call" method clientObj.
Using the application.onDisconnect handler The server calls the application.onDisconnect handler when a client disconnects from the application. You can add code to this handler that notifies all other clients about this event, as in the following example: // On the server side you would have the following application.onConnect = function(newClient, name) { newClient.name = name; return true; } application.onDisconnect = function(client) { for (var i = 0; i < application.clients.length; i++) { application.
Handling events in a component-based application When you develop applications, be aware that using components introduces explicit onConnectAccept and onConnectReject events. You need to include code to handle these events. When you use components, you must modify the application.onConnect statement in your server-side code to include the application.onConnectAccept and application.onConnectReject event handlers. The last line (in order of execution) of your onConnect handler should be either application.
Suggested settings for different bandwidth speeds The default camera settings provide a good viewing experience for all bandwidth settings. However, you can experiment with different settings for different bandwidths. The code for setting the bandwidth speeds is as follows: my_cam = Camera.get(); my_cam.setQuality(bandwidthSpeed,quality) Use the following table as a starting point if you want to experiment with camera settings at different bandwidth speeds.
The Microphone class This section includes recommendations for optimizing your use of the Microphone class, including tips on avoiding audio feedback. Avoiding audio feedback If you’re using a microphone with external speakers and a reasonably high gain, you’re likely to incur audio feedback problems. To reduce feedback from speakers, Flash Media Server uses echo suppression, which you can implement by using the following command: my_mic.
The NetConnection class (client-side) If an HTML page containing a Flash application (SWF file) is accessed with a different domain name than the domain name the SWF file uses to access Flash Media Server, the connection to Flash Media Server will not be successful. This is a security feature of Flash Player. But in some cases, this may be inconvenient. For example, if a web page containing a Flash application is served on an intranet from http:/ /deptserver.mycorp.
The NetStream class This section includes recommendations for optimizing your use of the NetStream class, including tips on incorporating data into a stream, managing a stream’s buffer, and executing code when a stream has finished playback. Using multiple data types in a stream In addition to streaming audio and video, you can include data, such as a text message, in a stream. To add multiple data types to a stream, use the following method: NetStream.
Then, in the corresponding server-side ActionScript, you would add the following code in the main.asc file: application.onAppStart = function(){ trace("::: Application has started :::"); } application.onConnect = function(client){ application.acceptConnection(client); // Add methods client.prototype.sendInfo = function(name) { var slen = Stream.length(name); trace("slen: " + slen); return slen; }; } About buffering a stream For playback streams, the value returned by the NetStream.
The SharedObject class Shared objects can be used for a wide number of purposes, and can be designed and used in a number of ways. This section provides some items to consider as you begin using shared objects in your applications. About synchronizing shared objects Before attempting to work with a remote shared object, you should first check that the SharedObject.
On the other hand, if your application needs to send only information that has changed, then you should divide the data among multiple slots. This implementation reduces network traffic and thus enhances the performance of your application. It also minimizes the need for conflict resolution code, as multiple slots can be updated simultaneously without data collision.
Assign an owner A more complex strategy is to define a single client as the owner of a property in a shared object for a limited period of time. You might write server code to create a “lock” object, where a client can request ownership of a slot. If the server reports that the request was successful, the client knows that it will be the only client changing the data in the shared object.
Accept some changes and reject others Some applications can accept changes on a “first come, first served” basis. This works best when users can resolve conflicts by reapplying a change if someone else’s change preceded theirs. Use the SharedObject.send() method to increase your level of control over changes to objects Rather than relying completely on SharedObject.onSync to manage synchronization activities, use the SharedObject.send() method as appropriate. The SharedObject.
About the Video class This section includes recommendations for optimizing your use of the Video class, including tips on dynamically creating Video objects. For more information about video, see Chapter 4, “Working With Media Files.” About creating Video objects dynamically You can add Video objects to your application only from within the Flash authoring environment, by dragging an embedded Video object from the Library panel to the Stage.
4 CHAPTER 4 Working With Media Files Macromedia Flash Media Server lets you deliver a broad range of media experiences. This chapter includes information about creating live web-event broadcasts, customizing stream delivery for individual clients, and MP3 publishing and playback. Working with video Flash Media Server lets you stream live and recorded video to Flash Player clients. Several features make Flash Media Server powerful for video delivery.
Customizing stream delivery You can use the Flash Media Server custom stream delivery feature to provide the best streaming experience for each client by serving different versions of the same stream to different clients. For example, you can provide video encoded with the Sorenson Spark codec to clients with Flash Player 7 and video encoded with the On2 VP6 codec to clients with Flash Player 8. You can also provide video encoded at different bit rates based on the bandwidth of the client.
Consider the following example: a user wants to play a stream and has Flash Player 8 installed on their computer. Flash Player 8 is capable of playing On2 video. Flash Media Server requests the HappyStream.flv file. After contacting the server, Flash Player 8 determines the value of the server-side Client.virtualKey property. The virtualKey property maps to the On2 streams directory, instead of to the default streams directory and the HappyStream.flv stream encoded with the On2 codec is played.
Within the VirtualKeys tag of the vhost.xml file, set the virtual key for Flash Player 7 and below to fp7 and set the virtual key for Flash Player 7 (7.0.19.
By default there are no values in the Key tags. To implement this feature, you must add the key values, either directly in the vhost.xml file, or with the Stream.setVirtualPath() method.
Working with MP3 files In Flash Media Server applications, you can use client-side ActionScript to play MP3 audio files and to display the ID3 tags of MP3 files, and use server-side ActionScript to publish MP3 files over a stream. To do so, upload the MP3 files for your application to the /streams/application_instance subdirectory in your registered application directory.
To display the ID3 tags of MP3 files, precede the stream name with id3: and define a callback function to capture the ID3 data. For example, to display the ID3 tag of bolero.mp3: // displays the ID3 tag of bolero.mp3 mystream_ns.play("id3:bolero"); // callback function to capture the ID3 data. Data will be displayed with // "info." preceding the data from the tag, for example, info.songtitle. mystream_ns.
To use the Stream.play() method to capture and display the text of ID3 tags, see the following example: // Set up the server stream application.myStream = Stream.get("description"); application.myStream.onId3 = function(info) { for (i in info) { trace(i + ": " + info[i]); } } if (application.myStream) { // Publish the ID3 text tag data of bolero.mp3 to a stream "description". // Use the id3: prefix in front of the stream name and specify 0 for the startTime parameter application.myStream.
CHAPTER 5 5 Debugging and Monitoring Applications The Macromedia Flash Media Server 2 management console lets you control applications, users, and servers. This chapter covers how to view application usage, stream data, and shared object data. For information about adding and removing server and vhost administrators, viewing server performance statistics, and starting and shutting down servers, see Managing Flash Media Server.
Connecting the management console to a server When you open the management console, you use the log-on screen to connect as an administrator to the server that is running the applications you want to manage. The login screen of the management console lets you connect to a server. To connect to a server: 1. In Windows, from the Windows Start menu, select Programs > Macromedia > Flash Media Server > Console. In Linux, open the fmsconsole.
6. To connect to this server automatically whenever you open the management console, select Automatically Connect Me. 7. Click Login. TI P The initial screen of the management console also has numerous links to Flash Media Server resources such as the Developer Center, Support Center, release notes, documentation, and online help.
The View Applications panel lets you perform the following tasks: ■ To manually load an application instance, click New Instance and select the application from the pop-up menu. The application must already be configured on the server. After selecting an application to load, you can enter a name for the application instance. ■ To view information about a running application instance, select the application in the list. The Live Log panel appears (see “About the Live Log panel” on page 69).
About the Live Log panel The Live Log panel displays the log messages by the selected application instance on the server, such as trace () statements in the application. The information in this panel is updated whenever the application instance generates a log message, not just when the panel is refreshed. (If you pause the console refresh feature, you still receive log messages.) The Live Log panel shows log messages for the selected application instance.
About the Clients panel The Clients panel displays detailed information about all of the clients connected to an application, including server-generated Client ID, connection protocol, bytes in and out, connection time, messages in and out, and dropped messages. The Clients panel shows information about clients connected to the selected application instance.
Drops indicates the number of messages that have dropped since the client connected. For live streams, audio and video, messages may be dropped; for recorded streams, only video messages are dropped. Command messages are never dropped. This panel lets you perform the following tasks. ■ To customize this panel, click the pop-up menu in the far-right column and select the columns to display.
Shared objects can be remotely persistent (they are stored on the server and are still available after an application instance or server is stopped and restarted), or available only for the life of the instance (they are temporary, and are deleted when the instance stops running). The Shared Objects panel displays information on both types of shared objects that the application instance uses. To display information about a particular shared object, click the object to select it.
About the Streams panel The Streams panel lets you view information about and play streams. The information is automatically refreshed every 5 seconds, or you can click Refresh to refresh at any time. The Streams panel provides details about streams and lets you play a stream. The Streams panel displays the following information.: Name indicates either the stream name or NetStream ID. For NetStream streams, the name is the NetStream ID (a server-generated number).
The Streams panel lets you perform the following tasks: ■ To customize this panel, click the pop-up menus and select or deselect the columns to display. ■ Click Play Stream to start playing the selected stream in a separate window that is the size of the selected stream. (To play the selected stream, you need to made a debug connection. For more information, see “Using a debug connection” on page 76.) You can only play named streams.
The Performance panel displays the following information: Clients provides information about clients connected to this application instance including the total number of clients who connected to the application instance since it started, active clients, and the number of users whose attempts to connect to the application instance were rejected. (To determine why connections might have failed, look at the Live Log panel in the management console.
Using a debug connection For playing back streams and obtaining data from shared objects, the management console must make a special debug connection to the server. By default, the server does not allow this. You must change this in Application.xml. NO TE The debug connection counts as a regular user and counts against license limits. To enable a debug connection: ■ In the Application.xml file, set true. After the change is made in Application.
For more information about the values that various onStatus handlers return, see the ClientSide ActionScript Language Reference for Flash Media Server 2. The following table summarizes the information objects that certain server-side calls return; the server-side call on the left invokes the client-side NetConnection.onStatus handler with the code value on the right. (This information is not included in the Client-Side ActionScript Language Reference for Flash Media Server 2.
About the System.onStatus handler In addition to the specific onStatus methods provided for the classes listed in “About onStatus event handlers” on page 76, Flash also provides a “super handler” called System.onStatus. If onStatus is invoked for a particular object with a level property of Error and no function is assigned to respond to it, Flash processes a function assigned to System.onStatus if it exists.
Tracing the properties of an object To find out why you might be having problems with a particular object, you can iterate its properties as follows: for (i in my_obj) { trace(i + " = " + my_obj[i]); } Tracing the properties of an object 79
Debugging and Monitoring Applications
CHAPTER 6 6 Application Development Tips and Tricks This chapter points out some useful information about application development that is specific to Macromedia Flash Media Server. It includes general sections on application design and coding conventions. Read this chapter after you are familiar with the concepts described in Chapters 1 and 2. About file types and paths When you use methods that record audio, video, or data streams (for example, NetStream.
To avoid overwriting streams, consider using unique names for users, streams, and so on. For example, when recording a new stream, you could provide an incremental value: outStream.publish("myRecording" + numSnaps, "record"); For information on deleting recorded stream files, see “The Stream class” on page 55. For more information on instance names and file storage, see the NetConnection.connect() and NetStream.publish() entries in the Client-Side ActionScript Language Reference for Flash Media Server 2.
Remotely persistent shared objects You create remote shared objects that are persistent only on the server by passing a value of true for the persistence parameter in the client-side SharedObject.getRemote() command or in the server-side SharedObject.get() command. These shared objects are named with the extension .fso, and are stored on the server in a subdirectory of the application that created the shared object.
If your SWF file is on the same computer that is running the Flash Media Server, you can use rtmp:/appName/instanceName as a shortcut version of rtmp://server.domain.com/appName/ instanceName. If you are authoring your application on a development server and don’t use a relative path in your SWF files, moving all of your SWF files to a production server could create some extra work, because each Uniform Resource Identifier (URI) in the NetConnection.
In contrast, suppose you use the call() method from the client, to call a method on the server side: // This is client-side ActionScript in the FLA file. NetConnection.call("someServerMethod"); // This is server-side ActionScript in the main.asc file. client.prototype.someServerMethod = function(){ // code here } // The following code would also work. application.onConnect = function(newClient) { newClient.
On the server side, you must implement slightly different code; server-side ActionScript does not contain a global object. The following code includes a file called my_file.asc: if (_my_file_asc == null) { _my_file_asc = true; // All the code for myfile.asc goes here. } Also, instead of using the #include command, the server-side script uses a load command, as follows: load("my_file.
To package server-side scripts in an archive file: 1. Open your operating system’s command shell. 2. Enter far -package with the desired options at the prompt. NO TE If the main script refers to scripts in a sub-directory, the hierarchy must be maintained in the archive file. To maintain this hierarchy, Macromedia recommends that you run the FAR utility in the same directory where the main script is located.
To understand how to use a FAR file in an application, consider the following example, which is based on an application called testFAR. The following is the directory of the testFAR application:. The main script is called testFAR.asc and is located in the scripts directory: The testFAR.asc file uses the web services that are provided in the script library directory (\scriptlib).
Now the scripts are ready to be packaged into a FAR file. Open the Archive Compiler utility in a command shell and run the following command: far -package -archive main.far -files testFAR.asc webServices\*.asc Finally, replace the scripts folder in the application directory with the main.far file. To verify the content in the FAR file, open the file in WinZip. It is important to verify that the path of the scripts inside the FAR file is set so that the main script can refer to the scripts correctly.
To compile server-side scripts to bytecode: 1. Open your operating system’s command shell. 2. Enter far -compile with the desired options at the prompt. NO TE Add the location of the FAR utility to the PATH environment variable. This addition lets you run the FAR utility without having to specify the full path to the executable.
Option Description -n Optional. Do not display the Macromedia copyright logo when running this utility. You may want to set this option if you are running the utility from an automated script. -h [] Optional. Displays the help for using this utility. You can optionally specify a command after the -help option to get more detailed help on a particular command option.
Managing bandwidth You can control the amount of data the server sends to each client by providing an approximate bandwidth capacity. You can do so in several ways. One way is to configure the capacity for the Flash Media Server in the configuration file (Config.xml). For more information on this technique, see Managing Flash Media Server. Another way is to use NetStream.receiveVideo() to specify the frame rate per second of the incoming video.
Or the design can be more detailed and include content switching in the NetStream, as in the following: ns = new NetStream(nc); ns.onStatus = function(info){ if (info.code == "NetStream.Play.InsufficientBW"){ // Switch to play a content that requires less bandwidth. curTime = this.time; this.play("foo_low_bandwidth", curTime, -1, true); } } vid.attachVideo(ns); ns.setBufferTime(2); ns.
About unloading and reloading applications Application instances are usually unloaded because of garbage collection. The first time the garbage collector runs after all clients are disconnected from an application, the application is unloaded. In other words, applications aren’t unloaded immediately when all clients disconnect.
If you set the read access as follows: client.readAccess = "appSO/" the server allows all connected clients to subscribe to shared objects with names that begin with appSO. Similarly, you can make the call: client.writeAccess= "appSO/public/" and the client can create only shared objects with names that begin with appSO/public, such as appSO/public/foo, but is denied access to appSO/private, and so on.
To use RTMPS, you replace rtmp in your NetConnection.connect call with rtmps. If you don’t specify a port number, Flash Player connects on the default secure port, port 443. A secure port is designated with a minus sign. For example, :1935,80,-443. This example specifies that Flash Media Player listens on any interface on port 1935, 80, and 443, where 443 is designated as a secure port that receives only RTMPS connections.
This section provides information about creating protected objects (also called system objects) and provides examples of how to make both synchronous and asynchronous calls to those objects. Understanding system objects A system object is a built-in or user-defined object wrapped in C-layer code that protects the object from application code. All calls made on the system object are passed through the C wrapper; the object can never be accessed or inspected directly.
Simple-system call example The following simple-system call example implements an ID generator. The generator must generate an increasing number for each new ID. If you write the generator code in the main.asc file, any part of the script could easily redefine the nextID() function or directly modify the _nextID value, as in the following: idGen = {}; idGen._nextID = 0; idGen.nextID = function() {return this._nextID++;} If you move the generator code to the secure.asc file, it loads before the main.
The following secure.asc example shows how to wrap a built-in global function—in this case load(). After secure.asc is executed, calls to load() are directed through the user-defined system call, as follows: var sysobj = {}; sysobj._load = load; // Hide the load function. load = null; // Make it unavailable unpriviliged code. /*The following function lets you inspect the file being accessed and, if necessary, modify or validate it.
The Flash Media Server does not maintain privilege levels explicitly. For example, an asynchronous call set up by normal application code cannot be privileged. However asynchronous calls set up within the system object can choose to complete the calls either as privileged or unprivileged. Consider the following example of a secure.asc file: // The following code is within a system call implementation: var resultObj = {}; resultObj.
Coding conventions This document outlines a system of best practices specifically designed for coding with ActionScript and building applications with Macromedia Flash. Applications that use these guidelines should be more efficient and understandable—and the underlying ActionScript code is easy to debug and reuse. NO T E You can use ActionScript 1 or 2 to write client-side scripts. You can use ActionScript 1 or JavaScript 1.5 to write server-side scripts.
Because ActionScript is based on ECMAScript, application authors can refer to current and future ECMA specifications to view a list of reserved words. Although Flash does not enforce the use of constant variables, authors should still use a naming scheme that indicates the intent of variables. Variable names should be lowercase or mixed case with a lowercase first letter, and constant names should be all uppercase.
For more information on strict typing and code hints, see Learning ActionScript 2.0 in Flash or search for “strict data typing” or “code hints” in Flash Help. Commenting your code Always comment code in an application. Comments are the author’s opportunity to tell a story about what the code was written to do. Comments should document every decision that you make while you build an application.
Initializing applications Initialization of an application is used to set the starting state. It should be the first function call in the application. This function should be the only call for initialization made in your program; all other calls should be event driven. // frame 1 this.init(); function init() { if (this.inited != undefined) return; this.inited = true; // Initialization code here } Using var for local variables All local variables should use the keyword var.
In this case, the counter variable on the main timeline is overwritten by the counter variable within the function.
Application Development Tips and Tricks
Index Symbols #include command 85 A ACL (access control list), implementing 94 ActionScript client-side and server-side 85 commands for connecting to server 19 execution modes 97 including other scripts 85 server-side information objects 77 supporting code hints 102 active connections, in Performance panel 75 Application class about 39, 42 acceptConnection() method 44 onConnect handler 43 onConnectAccept handler 46 onConnectReject handler 46 onDisconnect handler 45 Application Instance panel 67 application
B bandwidth and microphones 48 bytes per second 75 management console, viewing in 75 managing 92 speed settings 47 bytecode, compiling scripts to 89 bytes, in and out 70 C Camera class about 38, 46 attachVideo() method 46 bandwidth settings 47 get() method 38 tips and tricks 46 Camera.attachVideo() method 46 Camera.get() method, and Video object 38 Camera.
D deleting recorded stream files 55 deploying applications 15 designing applications for interdependence 84 for portability across servers 83 Developer Center for Flash Media Server 9 development environment, setting up 11 directories, naming 83 Display ID 70 documentation for Flash Media Server 8 double-byte applications 12, 93 Dreamweaver MX 93 duplicateMovieClip() method 56 dynamic access control 94 E edge servers 57 event handlers, onStatus 76 external data sources 26 F FAR files scriptlib path, inclu
L level property. See information objects Linux 12 Live Log panel 69 live stream. See streams loading the components.asc file 13 LoadVars class 39 local shared objects. See shared objects local variables, using var for 104 localhost, and NetConnection.connect() method 20 log messages. See management console M main.
NetStream.attachVideo() method 46 NetStream.bufferLength property 50, 51 NetStream.bufferLength propery 51 NetStream.bufferStream property 51 NetStream.bufferTime property 51 NetStream.play() method 38 about 40 and ID3 tags 63 and Video object 38 NetStream.publish() method 18, 38, 40, 81 NetStream.receiveVideo() method 92 NetStream.send() method 50 NetStream.setBufferTime() method 51 NetStrream.
file location 82 file types 19 flushing on server 53 local 38, 41 locking 54 management console, viewing in 71 name, viewing 71 persistence, local and remote 82 properties, viewing 71 proxied 42 read/write access, controlling 94 remote 42 See also SharedObject class server-side 40 slots 52 SOL and SOR file types 19 SOR file type 19 synchronization problems, avoiding 53 synchronizing 52 tips and tricks 52 tracking high score 54 type, viewing 71 types of 82 unlocking 54 Shared Objects panel 71 SharedObject cl
T technical support 9 text, encoding 55 third-party resources for Flash Media Server 9 troubleshooting application won’t connect to server 78 NetConnection.Connect.Failed message 78 type of stream, in Streams panel 73 U unloading and reloading applications 94 URI (Universal Resource Identifier) and Flash Player security 49 relative or absolute 83 shortcut for specifying 83 targetURI parameter 20 using localhost 20 UTF-8 format about 55 and double-bye applications 93 enabling in Dreamweaver MX 93 Video.
