This content has been marked as final. Show 3 replies
Flex provides different levels to handle asynchonous calls. I think you already know, but I am still going to repeat them. Call can be handle as service result, method result or request result..
<RemoteObject destination="getMyDataService" result="handleServiceResult(event)">
<method name="getMyItem" result="handleMethodResult(event)"/>
var responder1:MyResponder = new MyResponder(datagrid1);
var token1:AsyncToken = remoteObject.getMyItems("all java books");
token1.responder = responder1;
var responder2:MyResponder = new MyResponder(datagrid2);
var token2:AsyncToken = remoteObject.getMyItems("all actionscript books");
token2.responder = responder2;
In the request level example, the blocked calls need much more time to render data in 2 datagrids, but asynchonous one take advantage to cut the time in half
I cannot say asynchonous call better, but it does have its merit point, and Flex different levels of handling asynchonous call make the code easier already for different situations.
If you can provide your scenario which async call is hard to implement, it would be great to share.
I agree that for populating forms and grids its nice to do this asynchronously. However when I want to do transactions not having a synchronous call is not nice and leads to significently more complex client side code than is necesssary.
A simple example is when I need to perform 2 remote calls - and the second call needs to be executed after the first call completes. Instead of having some simple code in one method that calls both remote methods my client side code becomes fragmented - making the logic more difficult to follow. Our concern is that as the size and complextity of the app grows this is just unnecessay complexity.
We are just trying to understand why its been done this way (and the simpler case ignored) and if we have missed something obvious.
The reason that all remote calls are asynchronous is because the Flash Player is essentially single-threaded. Yes, the remote calls happen on another thread, but you can't make use of it. All UI processing is done by a single thread, so a blocking call will freeze up the entire app.
Yes, this does make certain processing more difficult. You'll have to get used to "chaining" your calls in those cases where the order of calls is important. You can implement a class to do this for you (ie. provide a list of functions to call and then have the callback of one function call the next function).