Some quick pointers (I do the framework stuff where I work):
All (afaik) network requests are queued up until the end of frame, so you
can nearly always add responders to a token...
...Except request errors, such as an invalid SOAP request. These can in some
circumstances generate Fault exceptions that never make it to the token :(
Here's some example code:
// ...
//This code is to catch invocation problems, since Flash has
decided to interrupt the flow of the VM for
//FaultEvent rather than dispatch it on next frame from the
token
operation.addEventListener(FaultEvent.FAULT,
invocationFaultHandler);
//Send the request
log.debug("Sending request...");
token = operation.send();
log.debug("...Send attempt completed");
//Remove our invocation fault listener
operation.removeEventListener(FaultEvent.FAULT,
invocationFaultHandler);
//Do we need to send this info on to the token's listeners in a
frame or two?
if (invocationFaultEvent) //Instance-level global
{
log.debug("There was an invoke error, which means the token
listeners aren't notified. Will redispatch to them in 250ms");
//When we create the timer, we're using a hard listener
reference because this helper instance may otherwise be collected before
we're done!
//So make sure to remove the handler (and kill the timer) on
firing!
timer = new Timer(250, 1);
timer.addEventListener(TimerEvent.TIMER,
reDispatchInvocationFault);
timer.start();
}
return token;
}
private function invocationFaultHandler(event : FaultEvent) : void
{
log.error("A fault occured during invocation");
this.invocationFaultEvent = event;
}
private function reDispatchInvocationFault(event : TimerEvent) :
void
{
//Important!
timer.removeEventListener(TimerEvent.TIMER,
reDispatchInvocationFault);
timer.stop();
timer = null;
token.mx_internal::applyFault(invocationFaultEvent);
}
On Fri, Dec 12, 2008 at 4:08 AM, Seth Hodgson <shodg...@adobe.com> wrote:
> I haven't been following this thread, but the sample code below can
> actually be shortened to something like this:
>
> save(xml).addResponder(new AsyncResponder(handleResult, handleFault));
>
> No AsyncToken in the code and rather than new'ing the responder, if you
> always want to direct results/faults to a consistent pair of handler
> functions you could set up the AsyncResponder earlier and just pass in a
> ref.
>
> save(xml).addResponder(saveResponder);
>
> The only reason to actually get a ref to the returned AsyncToken is if you
> want to add some dynamic properties to it that will help drive your handling
> of the eventual async result/fault (the token - and any custom state you've
> tagged it with - is accessible within your result/fault callbacks when they
> execute).
>
> But for scenarios like that where I want to hang onto some data from the
> call site, I often find it simpler to take advantage of the variable/scope
> capture that a closure provides by defining my result/fault callbacks as
> inline lambda functions rather than manually "capturing" state by copying a
> portion of it into properties of the AsyncToken. So something like:
>
> save(xml).addResponder(new AsyncResponder(
> function(... , // inline
> result handler function
> function(... // inline
> fault handler function
> ));
>
> Rather than new'ing an HTTPService for every call you make and trying to
> manage adding/removing event listeners (which will prevent instances from
> being GC'ed) in your wrapper I'd recommend just following the first
> convention I list above for each call: someMethod(args).addResponder(new
> AsyncResponder(handleResult, handleFault));
>
> Best,
> Seth
>
> From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On
> Behalf Of Mark Carter
> Sent: Wednesday, December 10, 2008 7:23 PM
> To: flexcoders@yahoogroups.com
> Subject: Re: [flexcoders] Best practice for calling asynchronous functions?
>
>
> Thanks for all the responses.
>
> I hadn't really looked into the ASyncToken until now. However, for me it
> seems that using the ASyncToken would be limited to the implementation of
> the, for example, save(XML, Function, Function) method.
>
> The calling code doesn't need to know about it. In my opinion this is
> neater
> than something like:
>
> var asyncToken:ASyncToken = save(xml);
> asyncToken.addResponder(...
>
> Also, I don't like adding responders after the call has been made. I know
> it
> works, but still...
>
> Maybe I should start a new topic for this next question, but...
>
> ...in my implementation, I create a new HTTPService for each call. Any
> ideas
> how (in)efficient this is? As you can imagine, it keeps the implementation
> much simpler. No need for the ASyncToken. Just add new listeners each time
> a
> call is made. Everything is garbage collected..... Oh, hang on, what keeps
> a
> reference to the HTTPService?????
> --
> View this message in context:
> http://www.nabble.com/Best-practice-for-calling-asynchronous-functions--tp20930596p20948799.html
> Sent from the FlexCoders mailing list archive at Nabble.com.
>
>
>
> ------------------------------------
>
> --
> Flexcoders Mailing List
> FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
> Alternative FAQ location:
> https://share.acrobat.com/adc/document.do?docid=942dbdc8-e469-446f-b4cf-1e62079f6847
> Search Archives:
> http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups
> Links
>
>
>
>
--
"Therefore, send not to know For whom the bell tolls. It tolls for thee."
Like the cut of my jib? Check out my Flex blog!
:: Josh 'G-Funk' McDonald
:: 0437 221 380 :: j...@gfunk007.com
:: http://flex.joshmcdonald.info/
:: http://twitter.com/sophistifunk
