// you’re reading...

ActionScript 3.0

EventDispatcher is fast and NOT an Asynchronous process–duh!!

By diamondtearz ⋅ April 28, 2006 ⋅ Email This Post Email This Post ⋅ Print This Post Print This Post ⋅ Post a comment

I was using dispatchEvent and was worried that the next line of code would be run before the recipients of the dispatch had executed their code. Based on the trace that I got the response is immediate. This lead me to start thinking...

Does dispatching an event essentially mean that the next thing on the callstack is the execution of the associated method on the event handlers?

As I was Googleing it the answer started to make more sense Since the dispatcher is really grabbing an array of eventListeners and calling all of their methods this would happen before the next line of code is executed. for a split second I was worried that it might be an asynchronous process- you know like waiting or "onResult" to be called from a Remoting call.

So just to state the obvious so I can clarify it to the 6 ActionScript coders who have not read Moock's Essential ActionScript 2.0 or Elst's Object-Oriented ActionScript for Flash 8 here we go:

When you call the static EventDispatcher.initialize(myClass) on a class it is passed through the following function in the "EventDispatcher Machine" - err quick check- if it's illegal to post this code someone drom me a comment- preferably someone non-Adobe law affiliated.

-Where was I?

PLAIN TEXT
Actionscript:
  1. static function initialize(object:Object):Void
  2. {
  3. if (_fEventDispatcher == undefined)
  4. {
  5. _fEventDispatcher = new EventDispatcher;
  6. }
  7. object.addEventListener = _fEventDispatcher.addEventListener;
  8. object.removeEventListener = _fEventDispatcher.removeEventListener;
  9. object.dispatchEvent = _fEventDispatcher.dispatchEvent;
  10. object.dispatchQueue = _fEventDispatcher.dispatchQueue;
  11. }

it adds these methods to the given class.

The addEventListener(event, handler) method actually takes the handler object/function and pushes it to the "queue" for the stated event.
The one that I'm particularly interested in is the dispatchEvent(eventObj) method. Inside it you have the following lines:

PLAIN TEXT
Actionscript:
  1. this[eventObj.type + "Handler"](eventObj);
  2.  
  3. // Dispatch to objects that are registered as listeners for
  4. // this object.
  5. this.dispatchQueue(this, eventObj);

Line one essentially calls a method with the eventObject's name+Handler within your class

(e.g.; if your event object was {type:"burp", volume:10, sourFluid:true} it would call burpHandler internally before event calling the handlers that you requested be handled)

When the EventDispatcher is done handling it's own Handler business it passes the eventObject to the dispatchQue. Our main concern is line 30 the o.apply(queueObj, [eventObj]); If you are not familiar with this use of apply check out Foundation ActionScript for Flash mx 2004. Sham breaks it down pretty clearly. It basically takes the object o and runs it's function-queue(who in the hell decided how to spell that word )- passing it the parameters eventObj

PLAIN TEXT
Actionscript:
  1. function dispatchQueue(queueObj:Object, eventObj:Object):Void
  2. {
  3. var queueName:String = "__q_" + eventObj.type;
  4. var queue:Array = queueObj[queueName];
  5. if (queue != undefined)
  6. {
  7. var i:String;
  8. // loop it as an object so it resists people removing listeners during dispatching
  9. for (i in queue)
  10. {
  11. var o = queue[i];
  12. var oType:String = typeof(o);
  13.  
  14. // a handler can be a function, object, or movieclip
  15. if (oType == "object" || oType == "movieclip")
  16. {
  17. // this is a backdoor implementation that
  18. // is not compliant with the standard
  19. if (o.handleEvent != undefined)
  20. {
  21. // this is the DOM3 way
  22. o.handleEvent(eventObj);
  23. }
  24. if (o[eventObj.type] != undefined)
  25. {
  26. if (EventDispatcher.exceptions[eventObj.type] == undefined)
  27. {
  28. // this is a backdoor implementation that
  29. // is not compliant with the standard
  30. o[eventObj.type](eventObj);
  31. }
  32. }
  33. }
  34. else // it is a function
  35. {
  36. o.apply(queueObj, [eventObj]);
  37. }
  38. }
  39. }
  40. }

It actually does this for each item "i" in the que.

Now to return to my main point that lead me down this long winded exploration.

If I have the following:

PLAIN TEXT
Actionscript:
  1. dispatchEvent({type:"burp"})
  2.  
  3. blowItOut();

it is effectively the same as having this

PLAIN TEXT
Actionscript:
  1. for(var listener in dispatchQue){
  2.  
  3. dispatchQue[listener].lookDisgusted(eventObj) ;//Or whatever function the listener chose to handle the event
  4. }
  5.  
  6. blowItOut();

so unlike an asynchronous call where you call and wait for results- this happens immediately and predictably.  the methods on the  listeners are placed in the callstack and executed ahead of the "blowItOut()" method.

I know this was longwinded but honsetly - this was more for me to hammer it into my brain than for you to wonder why i didn't add a property "flavor" on my burp event. I just figured that I would put it out there in case anyone else had thought about it. If any part of this explanation is not clear or just plain wrong someone set me straight or clarify.  if someone knows how to spellcheck with Wordpress that's welcome information as well.

Print This Post

Discussion

No comments for “EventDispatcher is fast and NOT an Asynchronous process–duh!!”

Post a comment