In the last entry in this series on the Swiz framework, we looked at how the CentralDispatcher can make dealing with events a lot easier. Now I'd like to take a look at how Swiz makes interacting with an application server just as simple. Once again, the current version of the application and it's source code is available.

When we left off, we had successfully dispatched some events to the Controller, but now what? Since this is a small "User Viewer" application, we need to get some Users in there somehow. Which means we need to talk to an application server. The UserController receives an event at application startup that will trigger this, as we saw in the last entry. But to actually make the request to the server, Swiz provides some amazingly simple behavior to do this. Because my UserController extends the Swiz AbstractController, it gets access to these helper methods. The one we're insterested in here is "executeServiceCall()", and using it is about as straightforward as you can get:

public function loadUsers( event : Event ) : void
{
    executeServiceCall( delegate.loadUsers(), userLoadHandler );
}

executeServiceCall() takes two main arguments: the method to call to initiate the request, and the callback handler to run after the server call is complete. There are additional arguments for a fault handler and event arguments, but I want to keep this simple so I'll leave those out for now.

As you can see if you look at the source code, a UserDelegate is being autowired into the UserController. The delegate is responsible for actually making calls to remote services such as RemoteObjects, WebServices, and HTTPServices. The main issue with these service methods is that they are asynchronous, which means you do not know in advance how long the call will take, or which call will be completed first if multiple service calls are executed.

The asynchronous nature of service calls (and, indeed, most Flex events) may be the single most difficult thing for web developers to come to terms with. We're very used to handling HTTP requests, which essentially "start at the top and go to the bottom". Unless you use some kind of multi-threaded capabilities like CFTHREAD, everything runs in sequential order and when it's done, it's done. The idea of processes being fired off into the unknown to run and complete "whenever" requires a fundamental change in how we think about application flow.

The most common way that Flex developers deal with asynchronous service requests is to use the AsyncToken. An AsyncToken allows you to attach responder methods to the service call, so that whenever they complete, the token executes the appropriate responder method. Operations on all three remote service types (WebService, RemoteObject, and HTTPService) automatically return an AsyncToken when they are called. But it is up to the developer to attach a responder to the token. While it isn't very difficult to do, it's one more thing you have to remember to do and more lines of boilerplate code to type. Swiz removes the need for you to worry about it at all.

When you call executeServiceMethod(), Swiz automatically creates a DynamicResponder object and attaches your result handler methods to it. It then attaches the DynamicResponder to the AsyncToken. With one simple method call, your remote service call is ready to go and properly configured to handle the asynchronous result events!

My result handler method is also very straightforward:

private function userLoadHandler( event : ResultEvent ) : void
{
    users.list = event.result as ArrayCollection;
    Swiz.dispatchEvent( new Event( UserController.USER_LOAD_COMPLETE ) );
}

The result event's "result" property contains the data returned by the server. In this case, it's an ArrayCollection of Users. First, I set that collection of Users into a property in the controller (a custom ArrayCollection called UserListCollection, which I'll talk a bit about in a future entry). Lastly, an event is dispatched to let the rest of the application know that the loading of the User data is complete.

That wraps up this entry. In the next one I'll delve into my UserDelegate and explain how I am simulating calls to a remote server for testing and to allow folks to run the application without needing to configure an application server.

Comments Comments (2) | del.ico.us del.icio.us | Digg It! Digg It! | Linking Blogs Linking Blogs | 3670 Views

Comments

  • # Posted By Philip Bedi | 6/4/10 5:31 AM

    I am getting following error
    Severity and Description   Path   Resource   Location   Creation Time   Id
    1017: The definition of base class AbstractDelegate was not found.   ManagerApp/src/com/philip/managerdemo/delegate   MockUserDelegate.as   line 11   1275646174572   62006

    I have included following SWC file:
    swiz-0.6.4-flex3.swc

    Is it correct lib file?

    Thanks

    Philip

  • # Posted By Brian | 6/4/10 9:46 AM

    Hi Philip, the 1.0 RC is out so you probably want to look at the example I created for it? http://www.briankotek.com/blog/index.cfm/2010/5/19...