The Fancy Magic

Having been through a bunch of ways to implement this centralized even management I suppose some of you may want to the powerful method that makes all this work.

This method is really the magic behind everything, so as you read it be prepared for something powerful.

/**
* Re-dispatches any events received.
*/

protected function recieveEvent ( e : Event ) : void
{
        trace( "received event:", e.type);
        dispatchEvent( e );
}
 

         

Are you amazed yet?  OK, I suppose it's a bit short.  But this really is key to everything.  Because the EventManager is listening to an event from a dispatcher, when it hears that event, the EventManager needs to tell someone.  Problem is, the EventManager isn't really sure who wants to know.  So our solution is to make the EventManager a little bit like a crazy person, and make it just talk to itself.    Eseentially, the EventManager recieves the event and then redispatches it to itself.  Have a look at the diagram below for a general idea of how this works.




Before we discuss this diagram, it's important to note again that this is only pseudo UML.  Those arrows don't actually represent events moving around but this can give us an important way to visualize what's going on.  Because the EventManager is listening to the dispatcher, the data can flow from the dispatcher (on the right) to the EventManager (center). Similarly, because the ListeningObject (on the left) is listening to the EventManager,  data can also flow from the EventManger to the listening object. 

The problem is, at this point the event that originates with the dispatchers has already completed.  It's as if it ran out of breath.  Luckily, the EventManager can give it a second life through the clone() method in all Event classes.    There are a number of tutorials online about the clone() method and how to implement it for your custom events.  A lot of these tutorials however, tend to not demonstrate all of the reasons why it's important, and this type of re-dispatching is exactly one of those reasons. 

When you re-dispatch an event, Flash's built in EventDispatcher class calls the clone() method on your old event to make a new one.  If you had any type of special values in your event, such as an ID or XML object, and you forgot to override clone(), you would lose those values.  This happens because Flash's EventDispatcher will call the clone() method of your custom classes super class -- the plain old vanilla Event Class.    And since the regular Event class has no idea that you had special values in your custom event, it will never clone them.  So be sure to override clone() in your special CustomDollyTheSheepEvent class if you want to maintain those properties.

We won't go to much into how to override the clone method when making custom classes, but below is a code sample showing a custom event with a proper clone method. 

package com.pj_co.events
{
        import flash.display.Bitmap;
        import flash.events.Event;
        
        /**
        * ImageLoaderEvent simple custom event for the image loader class
        */
        public class ImageLoaderEvent extends Event
        {
                public static const   LOADED  : String   = "imageLoaded";
                public static const   ERROR   : String   = "errorLoadingImg";
                
                public var            image   : Bitmap
                public var            id      : int;
                
                
                
                public function ImageLoaderEvent( type : String )
                {
                        super( type );
                }
                
                public override function clone ( ) : Event
                {
                        var newEvt : ImageLoaderEvent = new ImageLoaderEvent ( type ) ;
                        
                        newEvt.image = this.image;
                        newEvt.id = this.id;
                        
                        return newEvt;
                }
        }
}

So that's the curtain, and what's behind it.  Click that next page link one more time for a conclusion and some info and challanges to be discussed in part II of this article.