Flash Remoting: The Definitive Guide

Preface

The Web has always been an expanding, changing medium. What was in vogue just a few years ago might be completely abandoned today, and what is in vogue today may be completely abandoned tomorrow. Java™ applets were considered a breakthrough technology that was going to revolutionize the Web when they first came out. Java applets failed to take hold for several reasons, chief among them the complexity of the Java language for nonprogrammers, the download size for anything more than a simple applet, and the security restrictions that effectively tied the hands of the applet. ASP was Microsoft’s attempt to replace Java applets with server-side applications. JSP learned from the mistakes of ASP and provided a much more robust solution by offering compiled pages rather than interpreted pages. ASP.NET, in turn, learned from the mistakes of JSP by providing a framework that can be accessible to a variety of different languages using a common runtime environment.

And Flash has learned from the mistakes of those early Java applets. The Flash browser plugin is small, self-contained, and ubiquitous. Flash is attractive to designers as well as programmers, and it provides rich functionality that enhances the end user’s experience. Also, a Flash movie looks essentially the same on a Windows machine as it does on a Macintosh.

Some things have not changed, however. The Web is still primarily based in HTML. Even though XHTML is coming into prominence, it is just a syntactically standardized version of HTML that conforms to XML specifications. Flash solves many of the deficiencies of HTML by improving on animation limitations of DHTML, allowing for true interactivity, offering greater cross-platform and cross-browser consistency, and allowing upgrades of the Flash Player without requiring the user to upgrade his browser. By making Flash consistent across platforms, Macromedia has ensured that the Flash designer can virtually eliminate the laborious trial-and-error work that HTML web page designers go through to keep their pages consistent across platforms and browser types.

Macromedia Flash Remoting MX, or simply Flash Remoting, first offered with Flash MX, allows sophisticated datatypes to be passed from the server to the client and back without the speed limitations, bulk, and manual serialization/deserialization required by the XML techniques in previous versions of Flash.

In a traditional HTML application, a typical user experience is like this:

1. The user comes to your site. He enters something into a search field and clicks the Submit button.

2. The user waits for a response from the server. His browser loads the page, allowing the user to view the search results.

3. If the results span more than one page and the user clicks the link for the next set of results, the search request is sent to the server again. The server conducts the search again and sends back the second page of results.

4. Again, a new page is loaded into the browser.

You can liken this experience to a very inefficient phone conversation with a friend. You ask a question and hang up the phone. Your friend calls back and answers the question, then hangs up. You call him back, add something to the conversation, and hang up again. Two tin cans with a taught string between them gives you a more advanced communication method. Yet this is similar to how the client/server communication with a browser operates, and it is the prevailing standard on the Web.

HTML can build primitive web applications, but its main advantage is its ubiquity. However, Flash Player 6, which plays back content authored in Flash MX (including Flash Remoting applications) has over 85% penetration and allows developers to deploy much more sophisticated web applications. Flash Player 7 is in public beta, and by the time you read this, the release version will be available. Flash Remoting offers seamless communication between the client browser and the remote server. Each revision of the Flash Player, whose uptake is much faster than browser updates, essentially upgrades the Web. Only minor changes have been made to Flash Remoting in Flash MX 2004 and Flash MX Professional 2004 (Flash Pro), although the latter offers enhanced support for SOAP-based web services. Regardless of whether you are using Flash MX, Flash MX 2004, or Flash Pro, the principles and examples shown throughout this book apply equally.

Singing the praises of Flash Remoting is not to say that HTML does not have its place—it clearly does—but Flash offers user interactivity closer to a desktop application than a traditional HTML web site. Also, because ActionScript’s syntax is nearly identical to JavaScript, web scripters can easily transition to Flash. Flash MX also introduced Flash UI components, which are configurable and skinnable interface elements, such as checkboxes and list boxes. In previous versions of Flash, UI functionality had to be created for each new application. Components allow developers to concentrate on the application’s functionality rather than worry about mundane aspects of buttons and form elements. Components share a common API that leverages easy-to-use methods. This brings rapid application development (RAD), familiar to Delphi and Visual Basic users, to Flash-based web applications. Components are also extremely flexible, allowing designers to skin the components to fit seamlessly with the site design.

Drumbeat 2000, a web development program from Elemental Software (later purchased by Macromedia), tried to abstract HTML into a visual interface by turning HTML elements into JavaScript objects. Strongly resembling Visual Basic, the interface of Drumbeat 2000 used drag-and-drop components that were thinly disguised HTML tags and server-side script objects. Unfortunately, HTML was not intended for a point-and-click environment or an event-based model. Drumbeat 2000 died a quick death because the HTML/JavaScript objects slowed down an already slow technology, although parts of it were rolled into UltraDev and Dreamweaver MX.

Flash, on the other hand, is designed around an event-based GUI that thrives on point-and-click interaction with efficient self-contained ActionScript objects. Flash allows designers to customize the user interface, limited only by their imagination. A Flash designer can utilize standard prebuilt interface objects or build his own to create the interaction between his application and the end user. The ActionScript programmer can use these components to call server-side methods through Flash Remoting. This allows the Flash movie to do what it does best—interact with the user—and allows the server-side application to do what it does best—process information.

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. As of 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.

Take, for example, an interaction with an online store. A typical HTML page can consist of dozens of files and be 20-100 KB or more. But what about subsequent pages? Even if a page is remarkably similar to the one that came before, each page is often loaded in its entirety from the server (unless that page is already cached locally, in which case it still has to be rerendered by the browser). Menus, headings, copyright notices, and so on might be identical on every page, yet they are reloaded each time. There has to be a more efficient means of downloading and rendering page content.

Enter the Flash Player and Flash Remoting. With Flash Remoting, the browser needs to download only the subset of information that has changed from page to page, which is typically fed from the application server. When you click a Search button in a Flash application that uses Flash Remoting, the request is sent to the server in a small ActionScript Message Format (AMF) packet, and another AMF packet is sent back to the browser. The Flash movie loads the information contained in the packet, such as a recordset, array, or other datatype, and utilizes it as needed.

If successive screens are highly similar, instead of loading each 25 KB page separately, Flash needs to download only the portion that differs—the information to be displayed instead of existing interface elements. If data is required, the AMF format ensures it can be downloaded efficiently in a mere few hundred bytes. There is no need to completely redraw the entire page as a new page loads in, because Flash Remoting is supplying only data from the server and the Flash movie uses the data as needed. Also, Flash can often download data in the background so it is ready when needed. In most cases, the user isn’t even aware that the server was contacted.

You can picture poor old HTML just sitting there thinking, “now why didn’t I think of that?” Developers are often slow to adapt, however. Many HTML developers are unwilling to admit that HTML, while apt for simple pages, was never designed for complex interactivity, animation, and sound. As such, it is not surprising that Flash is much more convenient for creating interactive sites. Nevertheless, Flash and Flash Remoting are bringing the same interactivity and usability to the Web that GUIs brought to the desktop a generation ago.