Using Flash Remoting from JavaScript (AIR)
Flash Remoting. The product now more commonly referred to simply as “remoting” is woven deep into the very fabric of many of Adobe’s technologies. It’s available in ColdFusion and LiveCycle Data Services on the server. Of course you know you can use it from Flash and therefore Flex on the client. Did you know however, that this also extends to JavaScript in AIR?
Understanding Flash Remoting
To level-set, Flash Remoting is a technology introduced as a product offering circa Flash Player 6. The idea was that XML, and by extension SOAP, were too heavy. They required too much memory on the client, and too much bandwidth going across the wire. This was especially noticeable as the number of records increased. Using XML also generally meant additional development time as existing logic was wrapped to be exposed as a service.
By contrast, Flash Remoting alleviates memory requirements by using a binary serialization of the data structures coming across the wire. This also generally means faster transmission of the data in both directions (to and from the server). The protocol is still HTTP, but the payload is binary. The other benefit of Flash Remoting is that via a server proxy (which is why the product existed), developers could talk directly to existing server logic.
While you’ll find Flash Remoting in a variety of Adobe products, you’ll also find various alternative implementations including both open source and commercial offerings.
Using Flash Remoting
So how does a Flash-based technology get leveraged from JavaScript? Well, it’s important to remember that the HTML control in AIR is integrated with Flash. Via a feature commonly referred to as “script bridging” it is possible to use Flash API’s directly from JavaScript. Since Flash Remoting is part of the core Flash Player functionality on the client, it can also be used directly from JavaScript.
Using remoting from JavaScript is actually really straightforward. The first thing you need to do is specify where on your server the remoting gateway exists. This can vary slightly depending on the implementation you’re using. I use ColdFusion 8 on the server, so my URL is “http://www.mydomain.com/flashservices/gateway”. Once you’ve got that piece of information you use the Flash NetConnection class to establish a connection to the server.
var GATEWAY = 'http://www.mydomain.com/flashservices/gateway';
var conn = null;
var response = null;
function doLoad()
{
document.getElementById( 'btnHello' ).addEventListener( 'click', doHello );
conn = new air.NetConnection();
conn.connect( GATEWAY );
}
Before you start sending data to the server, you’ll need a means to handle the response, which could be a “result” or a “status” (fault). You’ll want to write a JavaScript function for each case. In the case of a fault, you’ll want to look at the “description” property of the event passed to the function to learn more about what went wrong. What you’ll get in the case of a
“result” will vary depending on the implementation and the type of data being returned.
function doFault( e )
{
alert( e.description );
}
function doResult( e )
{
alert( e );
}
Calls to the server happen asynchronously, so you’ll need a way to tie the response events to the functions you just created. This happens via a Responder object instance. When creating a Responder, you pass the functions that you setup to use for the various response types (result and fault). Then the only thing left to do is to actually make the call. This happens via the NetConnection.call() method.
function doHello()
{
var name = document.getElementById( 'txtName' ).value;
response = new air.Responder( doResult, doFault );
conn.call( 'work.Greeting.hello', response, name );
}
Notice the first parameter to the NetConnection.call() method. This is a string that refers to the object you’re using on the server. If the technology you’re using uses packaging, then you’ll need to specify that as well. For ColdFusion, the package is the directory structure to the ColdFusion Component (CFC). After the package is the class you’ll be invoking. Finally, the last part is the name of the method on the class.
In this case, I’m using a simple string for data. More realistically you’ll want to send an object or array of objects. The specifics for doing this will vary slightly depending on the implementation of Flash Remoting that you’re using, but is generally exactly what you’d expect: an Array, an Object, or an Array of Objects (i.e. [{id: 1, name: 'Adobe'}, {id: 2, name: 'Flash Remoting'}]).
There’s a lot of documentation both from Adobe and the community on the deeper uses of Flash Remoting, and I encourage you to continue exploring.
October 12th, 2007 at 5:27 pm
Are you aware of a non-AIR Javascript remoting interface.
October 13th, 2007 at 5:24 am
Incredible. A whole article and you haven’t made a reference to RIA! A stern word from Adobe marketing should bring you back ‘on message’. I wish I was a ‘Platform Evangelist’ too.
October 13th, 2007 at 7:44 am
I worked with HTML, JS, worked with AS. But seldom integrated them together, especially this way. It’s really interesting
October 16th, 2007 at 1:18 pm
Scott,
Remoting uses the AMF protocol over the wire. It is a binary serialization of the data structures. JavaScript doesn’t provide any robust means of dealing with binary data, so there’s no way to make this work using only JavaScript. The closest relative for JavaScript is the JavaScript Object Notation (JSON). There are many implementations on the client and server for JSON.
Hope this helps,
Kevin
November 2nd, 2007 at 10:06 am
This is amazing. I just finished my first AIR app and this gives me some motivation to start the next one, just to play with remoting.
May 19th, 2008 at 1:57 pm
I think this is fabulous we can control flash by using JavaScript remote, this is really very amazing, good job kevin!
Somon G.