Hi Seth, It stems I think from the fact that the Async stuff in the SDK (AsyncToken, IResponder impls) are a little too closely tied to Flex's underlying remoting stuff. But I've already brought that up on the SDK dev list and it seemed you guys are on top of that issue.
The problem is that from the SDK's point of view, there is no request. There's no IMessage, there's nothing to wait on. However from the application's point of view, there is. If I'm going to go to the trouble of building a failing case and submitting a bug, I may as well include a patch. SOAPEncoder throws an exception when asked to build an incorrect request which is reasonable, but of course this happens before the token is returned to the application code, and the event is sent to the Operation (and WebService I assume) before the application gets a chance to register its interest. Is there a place in the SDK code where a non-visual component needs to do a callLater() that I can copy? Do they just use the old "new Timer(1,1)" trick? -Josh On Fri, Dec 12, 2008 at 9:29 AM, Seth Hodgson <shodg...@adobe.com> wrote: > 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 > > > ------------------------------------ > > -- > 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
