ActionScript.com The Flash/Flex ActionScript Developer Community

Saturday, May 17, 2008

You are here : Article

One method, 2 arguments (3rd optional)

Flash Remoting provides several different ways to set up your connection and responder objects. Options are nice, but when you're getting started (or even after you've done several projects) most of us just want to copy and paste the tutorial sample and get working with our live data. So here's what the constructor looks like for our class:

var remote:RemoteHandler = new RemoteHandler("FlashZen", "http://www.flashzengarden.com/gateway.php", true);

The first argument is the name of the remote service, then the path to the gateway file, and finally an optional true/false of whether you want a bunch of trace statements for debugging purposes (the default is false).

Here's how you actually make a remote call:

remote.serve("myMethodName", cacheTimeInMinutes, arg1, arg2, ..., argN);

The first argument is of course the name of the remote method. The second argument is the how long any cached data is considered "fresh." Put 0 (zero) in there and it'll always pull straight from the server.

All we need now is a listener

(or two or three if you want). We can set one up like standard AS2 listeners, like this:

var myListener:Object = new Object();
remote.addEventListener("ALL", myListener); //Using GDispatcher

myListener.onMyMethodName = function(obj) {
	trace ("

 Successful return of results" + obj.result);
}

And that's it. For more details, read the rest of the article, take a look at the sample file, and drop any questions here in the comments.

Better than cookies

You probably know about Flash Shared Objects. If you don't, check out a tutorial. Basically, they give us a way to store Actionscript Objects on the user's machine, tucked away in some directories somewhere that most users don't even know about. They're especially cool because:

They work across all the browsers on that machine. Visit a site in Mozilla, see your saved data show up in IE.

They don't get erased when the users deletes the browser cookies.

You can store Actionscript objects, arrays, and even classes with methods, not just measly little strings and numbers.

Many times the data being pulled from the server doesn't change that often. By utilizing these Shared Objects to store the results, we can give the users almost instant results, and save a little bandwidth in the process. This was probably the trickiest part of the code for me to write, but all you need to know is that if a method is called with the same arguments within the cache lifetime, no server call is made. Instead, instant results are pulled from the cache and broadcast as if they came from the server.

Room to grow

The classes for this API needed to be structured in a "dynamic" way that would allow any method to be called, and the response returned to the appropriate object. Using a little help from array access [ ] , Function.apply(), and the GDispatcher (distributed with permission, thanks Grant), it worked out. Of course the listeners you create will need to be updated when new server-side methods are added, but nothing in the "middle" needs to change.

Encapsulation. really.

I don't know about the rest of you, but encapsulation is one of those things I always want to acheive, yet so often I end up mucking it up with some hard coded "_global" or otherwise external values, especially when things start getting complex. This time I think I did okay. The RemoteResponder is going to broadcast a message when it receives the response from the server (or cache) and any and all listeners can respond. Listeners just need to have a method that matches the name of the remote method plus "on" tacked-on to the front. For example, if my remote call is "getName", then my listener would need a "onGetName" method (notice the change in capitalizing the first letter of the method name). Errors can be picked up by adding "Error" on the end, like "onGetNameError." The object broadcast in both cases is an event object (not just the return value), which means you'll need to access

obj.result

to get at the actual value that is returned from the server. So if my return value is an object with name and age properties, I would access the age property using

obj.result.age

One-stop shop

Thanks to Joey, I'm able to package up AS2 Flash Remoting files along with everything else, which means you don't even need to download or install them seperately. But wait- there's more! I've even used a combination of Grant's preloader (with my own flavor added) and Colin Moock's template setup for the .FLA structure. Now whenever I (or my students) start a new data-driven Flash app, I open up this template file, and a sizeable chunk of work is already done. Though I can't eliminate the server-side issues you have to deal with for your own Remoting (or LoadVars for that matter) setup, perhaps these classes and sample files will help you start Remoting until you get around one of the good (but thick) books on the subject and learn all the ins and outs. Even if you don't have any problems setting up Remoting, or if you just use LoadVars, maybe the extensive caching via Shared Objects will be of interest.

As always , if you have any bug reports, suggestions, or questions: the comments await you...

del.icio.us || Digg It || Technorati