Web DevCenter    
 Published on Web DevCenter (http://www.oreillynet.com/javascript/)
 See this if you're having trouble printing code examples


Flash Remoting: The Definitive Guide

Ten Tips for Building a Flash Remoting Application

by Tom Muck, author of Flash Remoting: The Definitive Guide
09/16/2003

Flash programmers use the Flash Remoting technology to connect to back-end application servers. Flash Remoting works with ColdFusion MX, J2EE servers, and ASP.NET servers. In addition, several open source projects have sprung up that allow you to use the Flash Remoting technology with PHP, J2EE, and Perl.

With Flash MX 2004 around the corner, many people are wondering what effect the changes will have on Flash Remoting. The short answer is that it won't have an effect. Flash Remoting continues to be the best way to create an RIA (Rich Internet Application). In fact, Flash Remoting has not changed much for the release of Flash MX 2004 or Flash Pro. While Macromedia has added many new data-integration features to Flash MX using SOAP and other methods, for the most part these new features are not designed for programmers building complex RIAs. The use of verbose XML in SOAP, for example, makes a web service call using SOAP about 400 percent bigger than a similar call to a Flash Remoting service, which uses a terse binary format (AMF or Action Message Format). More information on Flash MX 2004 compatibility with Flash Remoting can be found at www.flash-remoting.com/articles/fr2004pt1.cfm.

As I was writing the book Flash Remoting: The Definitive Guide, I compiled many useful examples, techniques, and tips that will help you deliver the most efficient RIA possible. In this article I will show you ten things to think about when building a Flash Remoting application.

Related Reading

Flash Remoting: The Definitive Guide
Connecting Flash MX Applications to Remote Services
By Tom Muck

Introduction

First, a bit of background. Flash Remoting is a server-side technology that integrates with existing application servers to provide a gateway between the Flash Player and remote services deployed on the server. A service can be a simple ColdFusion page (or CFC), a PHP or Perl script, a Java class, or an ASP. NET page or DLL. Flash Remoting allows developers to access remote services and web services from within Flash through a simple ActionScript API that is similar to JavaScript. Flash Remoting also allows developers to integrate Flash with existing client/server applications with little modification to provide a rich, robust user interface that can be deployed across browsers, platforms, and devices. In short, the Flash Remoting offers the most flexible, intuitive way to add an application server to your RIA. Now, on to the tips.

1. Clearly separate the your development team's tasks.

When you build a Flash Remoting RIA you are working with many different technologies: Flash design, Flash programming in ActionScript, an application server technology and the associated language (CFML, PHP, C#, Java, and so on), Internet protocols, database servers and SQL, and client-side HTML/JavaScript. Your application will have tremendous improvements in speed and performance if developers on your team concentrate on what they do best and don't try to overstep their ability. This starts with an efficient database design and ends with efficient ActionScript code on the client.

2. Clearly separate and optimize the functionality between client, server, and database.

A Flash Remoting application is a client/server application and can be a three-tier or n-tier model utilizing MVC (Model-View-Controller) or MVP (Model-View-Presenter) patterns. You should have a clean separation of all parts. The server-side services should be operable in any situation, whether being accessed by a Flash interface, an HTML interface, a desktop application, or other web service. For that reason, it is not advisable to use the Flash object on the server. For example, the following ColdFusion code uses the Flash object in a ColdFusion page:

<cfquery name="rs" datasource="Northwind">
SELECT ProductName FROM Products WHERE ProductID = #Flash.Params[1]#
</cfquery>
<cfset Flash.Result = rs.productname />

Because the Flash object was used in this server-side code, the service is not flexible: it can't be used by anything other than Flash. What if you wanted to use this service as a SOAP web service? You wouldn't be able to. A better technique would be to build this code as a CFC, which would make it usable in other situations:

<cfcomponent>
<cffunction name="getProduct" access="remote"> 
<cfargument name="ProdID" type="numeric" />
<cfquery name="rs" datasource="Northwind">
SELECT ProductName FROM Products WHERE ProductID = #ProdID#
</cfquery>
<cfreturn rs.productname /> 
</cffunction>
</cfcomponent>

3. Maintain an interesting user experience.

The most important aspect of building any application--and especially a web application--is to create a comfortable user experience. If the user is bored, frustrated, or disinterested, he will go elsewhere and probably never return. A good Flash movie can hold a user's attention, but the way in which the user interacts with the web application makes the difference between an application that is usable and one that just looks nice. One of Flash Remoting's prime uses is to create a user interface that does one of several things:

Flash components make it easy to create user interfaces, and Flash Remoting adds features that allow easy connection to databases and other programs. Flash has many advantages over HTML for user interfaces. With HTML it's click-wait-reload. The Flash Remoting technology adds true client/server communication to browser-based applications because it is not page-based; it is based on a single interface that loads once for the entire application. The Flash movie creates a one-time connection to the server. The application state is maintained within the Flash Player. Gone is the click-wait-reload approach of HTML. With Flash MX you can build your web application as a unit with Flash as the front end and your application server on the back end. The communication with the server is handled by Flash behind the scenes. When you build an application with Flash Remoting, the user experience is similar to what you would expect from a desktop application.

4. Handle server downtime (lack of a connection) gracefully.

There are many possible reasons for communication failure:

Whatever the reason, your application needs a reliable way to recover from the lack of a connection. In an HTML page, this is not a problem: the browser will force a time-out after a specified number of seconds of waiting for a response. In a Flash movie it is your responsibility to provide a fallback mechanism to handle the lack of a connection. You can do this in two ways:

The _global.System.onStatus event should be handled in your application so that any failed remote calls will be handled gracefully:

_global.System.onStatus = function () { 
  getURL("http://www.flash-remoting.com/try_again.html","_blank"); 
};

This code displays an HTML error page to the user when a connection to Flash Remoting cannot be made.

5. Use components wisely.

Components are one of the cornerstones of Rich Internet Application (RIA) development using Flash and Flash Remoting. Components make it easy to create rich interfaces, but they can also be responsible for an application getting bogged down with poor performance. Many of the Macromedia user interface components are very code-intensive when it comes to doing things like populating the component, sorting, and adding data. You should be conservative in your use of client-side code when dealing with components. Do as much as possible on the server. This can be as simple as performing a sort in your database rather than in your ActionScript.

6. Maintain a clean API.

An API can facilitate code reuse and ease of development by your team. One way to do this is by building modules. Keeping the code modular is not something that is confined to one style of programming. It's a concept that works in all cases. If you code is self-contained in modules, you have several advantages over code that is non-modular:

7. Optimize your loops and other code blocks that are executed repeatedly.

This is true of any type of programming but is even more important in ActionScript. Loops should be tested, timed, and optimized in all cases. One misplaced statement inside a loop could mean the difference between an instantaneous application response and a wait time of several seconds for your user. Don't frustrate your users with a wait. A one-millisecond delay inside a loop that loops 1,000 times equates to a full one-second delay.

8. Use OOP or OOP concepts when possible.

ActionScript 1.0 is a flexible language in that it allows for traditional procedural programming, but also has a strong concept of objects. If you program in Flash using an object-oriented methodology, your applications will benefit by being more easily maintainable. ActionScript 2.0 is even more suited to OOP methodology. Use strong typing when publishing for ActionScript 2.0.

9. Use broadcasters or callback functions in your responder objects.

The call to the remote service is utilized by Flash in the Flash Remoting responder object. A responder object is a simple object with onResult() and onStatus() methods. A responder object can take many forms, but the most flexible way to build a responder object is to make it independent of your user interface.

A broadcaster is a flexible, intuitive way to create responder objects. A broadcaster can be thought of as a simple notification service. When a call to a remote function returns a result, the broadcaster that you setup notifies your movie that the event has occurred. You setup listeners to listen for this broadcast.

A callback function is another technique you can utilize in a responder object. Callback functions are used in Flash all the time (when you attach a function to the click event of a button, you are utilizing a callback function). Pass a callback function name to your responder object when you make the remote call, and let the responder object call the function when the results come back from the server.

10. Cache objects on the client and on the server whenever possible.

On the client, use a cache object; on the server, use query caching within ColdFusion, or whatever caching functionality is at your disposal for the server you are working with. Caching involves utilizing stored data rather than executing code again and again. An example of this might be a recordset that delivers a drop-down list for an application. If the recordset is the same every time, you should only create this recordset one time. A cached version can be used for each successive call to the same service.

Conclusion

Once you get your head around Flash Remoting, you'll be amazed at what you can do with it. Applications can be built that display one simple screen to the user while delivering content through the back-end application server. Communication with the server is seamless and transparent to the user. This translates to a better experience for your end users. More information on Flash Remoting can be found at www.flash-remoting.com and at the Macromedia site.

Tom Muck is an extensibility expert focused on the integration of Macromedia products with ColdFusion, ASP, PHP, and other languages, applications, and technologies and is a founding member of www.communitymx.com">Community MX). He recently completed his latest book, Flash Remoting: The Definitive Guide, for O'Reilly.


O'Reilly & Associates will soon release (September 2003) Flash Remoting: The Definitive Guide.


Return to the Web DevCenter.

Copyright © 2009 O'Reilly Media, Inc.