Hi Josh, This sounds like a bug in SOAP serialization in the Flex SDK that's generating a Fault locally on the client (no networking involved) but apparently has a bug and does so incorrectly.
Would you mind logging a bug with test case if you haven't already? Thanks, Seth From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Josh McDonald Sent: Thursday, December 11, 2008 3:05 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Best practice for calling asynchronous functions? 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
