So, I guess here’s the obvious. SSR is a small AS3 remoting library. Stands for “Super Simple Remoting” because it’s simple. My goal when writing it was to make one library that works in Flash and Flex and handle logic that should be in every application. Personally I like using this in both Flash and Flex because I don’t forget how to use it. I always forget how to use RemoteObject so this makes a standard library for either.

So here’s an example of a bare minimum setup of SSR to make a remoting call.

import com.niarbtfel.remoting.RemotingConnection;
import com.niarbtfel.remoting.RemotingService;
import com.niarbtfel.remoting.events.FaultEvent;
import com.niarbtfel.remoting.events.ResultEvent;

var rc:RemotingConnection = new RemotingConnection("http://localhost/myGateway",3);
//gateway
//3 is the amf format

var rs:RemotingService = new RemotingService(rc,"MyService",4000,3,true);
//rc is the remoting connection to use for this service
//"MyService" is the service target on the server.
//4000 is the amount of time a call waits before retrying the call.
//3 is the amount of retries to attempt per call.
//true turns on call limiting, which means that the same exact call can't be made while one is waiting for a response or timeout.

//callbacks for calls, keep reading.
function onr(re:ResultEvent):void{}
function onf(fe:FaultEvent):void{}

//callbacks for calls, keep reading.
function onrArgs(re:ResultEvent,args:Array):void{}
function onfArgs(fe:FaultEvent,args:Array):void{}

rs.myMethod([],onr,onf,false); //make a call
//[] = call arguments
//onr is the result callback
//onf is the fault callback
//false - don't return the original arguments sent in the request to the callback functions

var mym:String = "myMethod";
rs.apply(mym,[],onrArgs,onfArgs,true); //make a call
//[] = call arguments
//onr is the result callback
//onf is fault callback
//true - return the original arguments sent in the request to the callback functions

This is the simplest form of setting up flash remoting with SSR without any event listeners on the RemotingConnection or RemotingService. Events for RemotingConnection and RemotingService are documented in the class files. You get events for things like disconnects, retries, timeouts, etc.

Each RemotingService can have a timeout specified for each call going to that service, as well as a maximum attempts allowed per call. If one call is made, but doesn’t receive a response within the timeout specified, it’s tried again. This happens over and over until the maximum attempts is reached, and a timeout event is dispatched.

RemotingService has an option to turn on call limiting. Which makes the remoting service smart about what to call and what not to call. If you made a call to “MyService.myMethod” with parameters ["something","something else"], it would not let you make that same call until the first one has completed, or has timed out. You’d still be able to make calls to any other service method.

Another new feature is caching. Say you make calls to some service numerous times, but the data is always the same. Instead of doing that you can enable the service to use caching. Here’s a snippet from above with caching in place:

var rs:RemotingService = new RemotingService(rc,"MyService",4000,1,true);
rs.remotingCache = new RemotingCache(-1);
//-1 specifies that the cache should never expire. (supply a time in milliseconds for an expiration if needed)

Now every call made through this remoting service will be cached. If the exact same call is made, the results are pulled from cache instead.

SSR also has paging built in with a RemotingPager. Here’s a snippet on how that works:

import com.niarbtfel.remoting.RemotingConnection;
import com.niarbtfel.remoting.RemotingService;
import com.niarbtfel.remoting.events.FaultEvent;
import com.niarbtfel.remoting.events.ResultEvent;
import com.niarbtfel.remoting.paging.RemotingPager;
import com.niarbtfel.remoting.paging.PageResponder;

var rc:RemotingConnection = new RemotingConnection("http://localhost/myGateway",3);
var rs:RemotingService = new RemotingService(rc,"MyService",4000,3,true);
var rp:RemotingPager;
var pr:PageResponder // just to include in compilation

var totalRecordsOnServer:int = 400; //should come from server instead.

//callbacks for calls, keep reading.
function onrArgs(re:ResultEvent,args:Array):void
{
  rp = new RemotingPager(rs,"myMethod",PageResponder,["someParameter"],re.result as Array,totalRecordsOnServer,50,2,1);
  myButton.addEventListener(MouseEvent.CLICK, onbc);
}
function onfArgs(fe:FaultEvent,args:Array):void{}

function onbc(me:MouseEvent):void
{
   if(rp.hasNext())
   {
     trace(rp.next());
   }
   else
   {
     trace("no more pages");
   }
}

rs.myMethod(["someParameter",0,50],onrArgs,onfArgs,true); //make a call to get the initial data.
//0 is the offset
//50 is the pagesize

In this example, a remoting pager is created in the result callback of the first call. A remoting pager needs at least the first page in order to be created. The RemotingPager takes care of “pre-fetching” pages with buffer options. In the above example, where the RemotingPager is created, 50 is the pagesize to grab, 2 is the amount of pages to buffer / pre-fetch. And 1 is the amount of pages that are left in the buffer before triggering another buffer fill / pre-fetch. This is the simplest form of paging, but the RemotingPager has methods for getting certain pages, getting them all, seeking, etc.

UPDATE: I forgot to mention RemotingService.MaxTimeoutsBeforeHault.

With RemotingService.MaxTimeoutsBeforeHault, you can control how many timeouts are allowed from any call, before all remoting calls are stopped. Here’s a snippet:

RemotingService.MaxTimeoutsBeforeHault = 3;
var rs:RemotingService = new RemotingService(rc,"MyService",4000,3,true);
rs.addEventListener(CallEvent.SERVICES_HALTED, onch);
function onch(ce:CallEvent):void{}
rs.myMethod([],onR,onF,true);

When you set this property, any call that causes a timeout, is kept track of, and if 3 timeouts happen from any call, no other remoting calls will be made. Each attempt after the services are halted, dispatches the CallEvent.SERVICES_HALTED event.

In conclusion – SSR gives you logic out of the box that should be available anytime we are using Flash Remoting. And gives you numerous other features. SSR 2 is documented very well in the source files.

UPDATE: Check out the SSR 2 Breakdown.

1. Connection fault handlers were not being called correctly. On status errors was not catching NetConnection.Call.Failure codes, as I had put NetConnection.Connect.Failure.
2. Fixed a try catch statement in the onResult function of RemotingCall.as.

http://ssr.riaforge.org/

import org.rubyamf.remoting.ssr.*;
var service = new RemotingService('http://localhost:8024/gateway.rb','some.package.MyService',3);
service.setCredentials('userid','pass');
service.addEventListener(FaultEvent.AUTHENTICATION_FAILED, handleAuthFailure);

function handleAuthFailure(e:*)
{
  trace("AUTHENTICATION FAILED");
}

There are a couple ways you can tell the Flash client that authentication failed. Here are RubyAMF examples:

EX: 1
import RUBYAMF_SERVICES + 'fault_object'
class MyService
 def _authenticate(user,pass)
   FaultObject.new(1,'Authentication Failed')
 end
end

EX: 2
class MyService

 def before_filter
  @auth = false
 end

 def auth_fail
  return FaultObject.new(1, 'Authentication Failed')
 end

 def _authenticate(user,pass)
  if #someprocessing
   @auth = true
  else
   false #returning false from _authenticate triggers the exception back to the flash player as well
  end
 end

 def myRestrictedMethod
  if !@auth
   auth_fail
  else
   #some processing
  end
 end
end

You can also trigger authentication errors from AMFPHP. EX:

<?php
class MyService
 function someMethod
  return {'faultString' => 'Authentication Failed', 'faultCode' => 1};
 end
end
?>

All of these examples will trigger the authentication failed event. Using this for authentication failure is nice so that you can handle authentication errors in on place. Not having to handle them in every onFault handler.

Download the latest