Flash Remoting Article

The application is a simple widget that gets the current time from the server and the IP address of your browser and returns it to Macromedia Flash.

Server-side ColdFusion code
On the server side, you will build the backend ColdFusion component. Open basic.cfc located inside the <webroot>\flashremoting\components\ folder. I suggest turning on line numbers in Dreamweaver MX to follow along with the discussion (To turn on line numbers, select View > Code > Code View Options > Line numbers.)

This example calls the today() function (see lines 14–19). The ColdFusion component has a simple cfset tag that builds the result and returns it with the cfreturn tag.

Client-side Macromedia Flash ActionScript and Flash Remoting code
For web application developers, looking at the Macromedia Flash code can be a bit foreign, so I'm going to explain it step-by-step. (Sorry about my lack of graphic design skills; this tutorial's purpose is instructional, not design-oriented—you designer types can fix this up for me.)

Open basicComponentUse.fla inside the Macromedia Flash MX authoring environment. Two objects are on the stage: a dynamic text box with the instance name of status and a big red button with the instance name of trigger. The button will execute an ActionScript function called getData() when the client presses it.

Select Frame 1 of the actions layer and open up the Actions panel or press F9. Display the line numbers to help you follow along as I explain the ActionScript code. (You can turn on line numbers in the panel menu.)

The first few lines include two ActionScript libraries. The first one, NetConnection.as, enables the application to connect to the Flash Remoting service. The second one enables the application to use the NetConnection debugger to examine the code as it executes. While the NetConnection Debugger is useful during development, you should remove it in your final application, as it adds overhead to your application.

Look at line 16:

NetServices.setDefaultGatewayUrl("http://localhost:8500/flashservices/gateway")

This is perhaps the single most important line of code: It tells Macromedia Flash where to find the Flash Remoting Gateway. If you did not install ColdFusion MX with its default setup, you must modify the URL in line 16 so that it specifies the location of your gateway.

The next line connects to the gateway and builds a connection object named cfserver. Typically, I recommend that you test your connection at this point to ensure that you have the correct gateway URL. This could be difficutl to verify without the NetConnection Debugger. It reports communication between Macromedia Flash and the server.

Lastly, create an object inside the Macromedia Flash ActionScript—this object represents the CFC on the ColdFusion server.

basic = cfServer.getService("flashremoting.components.basic", this);

Now, a Macromedia Flash developer can refer to the basic object, which contains all functions available in the basic.cfc, which is on the ColdFusion server.

Using the NetConnection Debugger
If you open the NetConnection Debugger and test your movie (Control > Test Movie or Control-Enter), you should see the following.

In the NetConnection Debugger, notice that the Macromedia Flash Player executes the connection statement to your Flash Remoting gateway and confirms that you can connect to it. This is probably where most people go wrong. Macromedia Flash will look for the Flash Remoting Gateway but it may not find it based on your setup. For more information on how the Flash Remoting determines its default gateway see TechNote 16352: How createGatewayConnection determines the URL.

If you click the movie button, you will see the Macromedia Flash Player call the today() method in the CFC on the server in the NetConnection Debugger. If your machine is slow enough, you can observe a delay between your request to the server and its response. For many developers, this process will shift their thinking; traditionally web application developers think of a program as a synchronous process. Here, it is not.

In this paradigm, the application is asynchronous. Your application sends a request to the gateway and then the gateway may (or may not) respond with an answer and it also might not be instantaneous. A skilled Macromedia Flash developer will hide this delay as they create an application.

When the client clicks the movie button, the button (inside the Macromedia Flash ActionScript) calls the function getData(). In this example, all that happens is that a function is called against our basic object, the today() function.

The second most common mistake I have seen most traditional, procedural-based programmers make: they immediately want to assign the function call to a result. This is not possible, however, because you do not know when Macromedia Flash will receive the result. Instead you must define an additional function that the server will call when it has gathered the data and has returned it to the Macromedia Flash movie. This function shares the name of the remote function call (in this case named today), but has a suffix of _Result, therefore, the function would be called, today_Result. This function will accept a parameter (the data it receives from the server).

 function today_Result(result)
  {
      // this sets the text property of the instance 'status' 
    to be the value of the result
      status.text = result;
  }

The today_Result function stores the data in the 'result' variable so you can use it later. In this case, I assign the result into the status text box. That is the end of the Macromedia Flash code. You are done!

In the next, more complex example, you'll learn how to get data from a database and display it in Macromedia Flash.