Many people are wondering if Flash Remoting still supported in Flash MX 2004. The answer is "Yes", however I think the next few months will be a transition period. The latest Flash Remoting components from Macromedia still utilize ActionScript 1.0 code, but the good news is that everything still seems to work. In this article I'll try to answer a few of those questions that have appeared since the release of Flash MX 2004 and Flash Professional.
Many of us who use Flash Remoting are surprised the first time we open up Flash MX 2004 or Flash Pro because our Flash Remoting .flas don't work immediately. As you recall, Flash Remoting was a separate download in Flash MX. That has not changed in Flash MX 2004. While it is surprising that Flash Remoting is not built into Flash MX 2004, it does not mean that FR does not work any more. Simply go to the Macromedia site and download the newly updated Flash Remoting components for Flash MX 2004, at http://www.macromedia.com/software/flashremoting/downloads/components/
Have the Flash Remoting components changed in Flash MX 2004? The answer to that is No. Flash Remoting is essentially the same as it was in Flash MX. The new location, after installing the components, is <Flash program directory>\en\First Run\Include . The NetServices class and related classes have had a few syntax errors and case issues fixed, but other than that they are basically the same. If you do a side-by-side comparison, you'll see that a few misplaced case errors were fixed (such as netDebugProxyCall in place of netDebugproxyCall and serverInfo in place of serverinfo ) and a few problems with new reserved words (the word class was used as a property in one of the FR files).
When you publish your Flash Remoting application, you can publish as ActionScript 2.0 (for Flash Player 7) or ActionScript 1.0 (for Flash Player 6). That may be surprising, since the files are still ActionScript 1.0 compatible, but ActionScript 2.0 is still a somewhat ?lazy? language. Or you could say that ActionScript 2.0 is simply backward compatible. In any case, the beautiful thing about ActionScript 2.0 is the fact that it can be strongly typed by declaring your variables, functions, and arguments using the type syntax of variable:type , and the fact that object-oriented programming is now fully supported using syntax that is instantly intuitive to people coming from OOP languages like Java. Classes are no longer prototype based as they were in ActionScript 1.0, but use the class keyword.
For a nice set of introductory articles to ActionScript 2.0, check out Joey Lott's site at http://www.person13.com/
The big question is this: do Flash Remoting applications built for Flash MX work in Flash MX 2004? Well, every app that I've tried works without change. If you were careful about the case of your code and didn't use any ActionScript 2.0 reserved words (such as class or Error ), you should have no troubles. I'll be sure to blog about any incompatibilities at http://flash-remoting.com/notablog/, but please drop me a line if you find problems in your own applications.
Why is there no connector for Flash Remoting in Flash Pro? You will have to ask Macromedia that question. Firefly, or the Data Connection Kit as it is also known as, had a connector to make it easy to connect Flash Remoting to UI components. The Firefly components seem to have been merged into Flash Pro minus the Flash Remoting connector, and Firefly is no longer sold by Macromedia. I thought it was a huge mistake to release Flash without connectors for Flash Remoting. I don't see too many situations where the SOAP connectors make sense over Flash Remoting, given the huge size of SOAP packets. Also, any advantage to having native SOAP translation in the Flash player is lost given that a SOAP transaction through Flash has to be initiated on your own server or on a server that has a cross-domain policy file set up for you. In short, if you want to use SOAP , you probably won't have access to the server and if you do have access to the server, you won't want to use SOAP .
The huge packet sizes of SOAP make it extremely inefficient to use in a rich internet application. Here's a SOAP packet for a typical service. A typical request envelope might look like this:
POST /com/oreilly/frdg/HelloUser.asmx HTTP/1.0
Content-Length: 355
Host: 192.168.0.15
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://oreilly.com/frdg/sayHello"
<?xml version="1.0" encoding="UTF-8"?>
<SOAP - ENV :Envelope xmlns: SOAP - ENV ="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP - ENV :Body>
<sayHello xmlns="http://oreilly.com/frdg/">
<username>Tom</username>
</sayHello>
</SOAP - ENV :Body>
</SOAP - ENV :Envelope>
This request was created by an ASP. NET application server upon receiving the GET request. The sayHello( ) method of the web service can be plainly seen within the envelope body, along with the username parameter that was supplied, ?Tom?. A response to that request might look like this:
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Wed, 01 Jan 2003 01:20:19 GMT
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Content-Length: 371
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<sayHelloResponse xmlns="http://oreilly.com/frdg/">
<sayHelloResult>Hello Tom. It is 8:20:19 PM</sayHelloResult>
</sayHelloResponse>
</soap:Body>
</soap:Envelope>
As a contrast in size, look at the AMF response passed to the Flash movie for an identical Flash Remoting service (unprintable binary characters represented as .):
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Wed, 01 Jan 2003 01:40:30 GMT
Cache-Control: private
Content-Type: application/x-amf
Content-Length: 59
......./1/onResult..null.......Hello Tom. It is 8:40:30 PM..
The Content-Length header tells the story: the SOAP version was 371 characters, whereas the AMF version was 59 characters. You can imagine that with more complex web services or services that are called repeatedly, the savings in bandwidth can be enormous.
Data binding in Flash Pro is overly hyped, but it amounts to a drag-n-drop interface to save you from typing one line of code. For example, to bind a remote SOAP service to a UI component such as a DataGrid, you have to follow manual steps to set the bindings of the DataGrid to the service connector. To do the same in Flash Remoting, you can do it with a line of code in your onResult() method:
myGrid.dataProvider = result_rs;
Programmers coming from other backgrounds such as Visual Basic or Delphi can appreciate the ease of setting properties and calling methods of components programmatically in the new component V2 architecture. This has not changed much since Flash MX.
The easiest example of Flash Remoting you will find is a simple Hello World example. This one is written for Flash MX, but will work as it stands on Flash MX 2004:
#include "NetServices.as"
var myURL = "http://localhost/flashservices/gateway";
var myServicePath = "com.oreilly.frdg.HelloWorld";
var myResult = new Object();
myResult.onResult = function (data) {
trace("Data received from Server : " + data);
};
myResult.onStatus = function (info) {
trace("An error occurred : " + info.description);
};
_global.System.onStatus = myResult.onStatus;
var myServer = NetServices.createGatewayConnection(myURL);
var myService = myServer.getService(myServicePath, myResult);
myService.sayHello();
This can be published as ActionScript 1.0 or ActionScript 2.0. This shows the lazy approach of the ActionScript language: variables are not typed in this example, but the movie will work regardless.
To demonstrate a very simple Remoting app that uses ActionScript 2.0 syntax and the new component architecture, here is the same Hello World service set up to work with a text field named message_txt and button named submit_pb to call the service:
#include "NetServices.as"
var myURL:String = "http://localhost/flashservices/gateway";
var myServicePath:String = "com.oreilly.frdg.HelloWorld";
var myResult:Object = new Object();
myResult.onResult = function (data:Object):Void {
message_txt.text = "Data received from Server : " + data;
};
myResult.onStatus = function (info:Object):Void {
message_txt.text = "An error occurred : " + info.description;
};
_global.System.onStatus = myResult.onStatus;
var myServer:Object = NetServices.createGatewayConnection(myURL);
var myService:Object = myServer.getService(myServicePath, myResult);
var simpleListener:Object = new Object();
simpleListener.click = function (evt:Object):Void{
myService.sayHello();
}
submit_pb.addEventListener("click", simpleListener);
One immediate advantage to typing your variables (as in myURL:String) is that code hints will work in the Flash authoring environment.
Another example is a typical search interface using a data grid. This version works with the new DataGrid that is part of Flash Pro:
#include "NetServices.as"
// Connect to the gateway and create a service object
if (connected == null) {
connected = true;
NetServices.setDefaultGatewayUrl("http://localhost/flashservices/gateway");
var my_conn = NetServices.createGatewayConnection();
var myService = my_conn.getService("com.oreilly.frdg.SearchProducts", this);
}
var simpleListener = new Object();
submit_pb.addEventListener("click", onSubmit);
// Event handler for button
function onSubmit () {
myService.getSearchResult(search_txt.text);
}
// Responder function for result
function getSearchResult_Result (result_rs) {
var temp = "";
temp += "There were " + result_rs.getLength();
temp += " records returned.";
results_txt.text = temp;
// The following line binds the recordset to the grid
myGrid.dataProvider = result_rs;
}
// Responder function for status
function getSearchResult_Status (error) {
results_txt.text = "There was an error: " + error.description;
}
The DataGrid example can be viewed at here, including server-side code for ColdFusion, PHP, Java, ServerSide ActionScript, and C#..
Despite the advantages of ActionScript 2.0 syntax, I still advise publishing Flash 6.0 movies for at least the next 12 months for any application that will be utilized on the web. The current infiltration of the Flash 6 player is great, but the Flash 7 player will not become commonplace on the desktop of average users for another year. Flash Remoting has only been around since May of 2002, after all. For company intranets where you know your audience is going to have the latest player, use Flash 7 format. Luckily, Flash offers the option to use ActionScript 2.0 and Flash Player 6 (which works in Flash Player 6.0.79 or higher).
When you install the Flash Remoting Components for Flash MX 2004, you will notice that the NetConnecton Debugger is conspicuously missing from the Window menu. The debugger is actually installed with the Remoting package, but is located under Window > Other Panels along with the Service Browser panel. Alternatively, you can go to <Flash program directory>\en\First Run\WindowSWF and open the debugger manually before beginning a debugging session. The debugger has a file modification date of 2/26/2003 in the current (as of 9/13/2003 ) implementation of the Flash Remoting Components, so it has obviously not been changed for the release of Flash MX 2004. The panel seems to work flawlessly in Flash MX 2004. Please email me if you find out otherwise.
Of course you can't utilize NetServices in any of your ActionScript 2.0 classes, but Joey Lott has already begun translating the Flash Remoting classes to ActionScript 2.0, at http://www.person13.com/flashremoting/. It's only a matter of time before Flash Remoting will be up to snuff on Flash MX 2004 and Flash Pro.
The initial reaction to Flash MX 2004 and Flash Pro has been mixed. Although the enhancements in the core player, including ActionScript 2.0, are impressive and highly anticipated, the current data binding implementation is a step backward because it is not readily available to Flash Remoting. Macromedia was ahead of the curve with Flash Remoting, but they appear to have taken a step back in the latest version of Flash MX, pushing SOAP ahead of its own AMF technology. Macromedia should use its resources to make AMF the standard for web services used by Flash, rather than fall back on the bulky SOAP standard.
What Macromedia needs to do is get the Remoting adapter onto every server out there, the same way that Flash is on every web browser out there. SOAP is simply too bulky to be of serious use in a client-server environment over the web. Sure SOAP , WSDL, and UDDI are great for small, publicly available services like Amazon, Google, and things like that. But they are really not suited for RIAs that need to pass packets back and forth on 56K lines to web browsers.
Luckily, AMF has taken off in a big way. It has been utilized by several open source projects available freely on the web, as well as several commercial solutions. AMFPHP, for example, (http://www.amfphp.org/) has completely mimicked the standard and created the best solution out there for connecting PHP to Flash. OpenAMF (http://www.openamf.org/) is a J2EE implementation of Flash Remoting that goes beyond what Macromedia's $1000 server component is able to do. FLAP (http://www.simonf.com/flap/) is a Perl implementation. FlashORB is a commercial solution (http://www.flashorb.com/) for J2EE with another in development for ASP. NET.
This article first appeared on Flash-Remoting.com.