Choosing a Flash Event Engine That?s Right For You

What event engine is right for you? Read on to find out! Careful, she’s a long one…

7 Replies to “Choosing a Flash Event Engine That?s Right For You”

  1. Hey J,

    You forgot to mention the EventDispatcher bug. Basically if you have a listener that removes another listener the listener that removed the other listener gets called twice if the listener being removed hasn’t been called yet.

    // Example
    import mx.events.EventDispatcher

    var o = new Object();
    EventDispatcher.initialize(o);
    o.broadcast = function(){
    this.dispatchEvent({type:”event”});
    }

    a = function(){
    trace(“a”);
    }

    b = function(){
    trace(“b”);
    }

    c = function(){
    trace(“c”);
    o.removeEventListener(“event”,b);
    }

    o.addEventListener(“event”,a);
    o.addEventListener(“event”,b);
    o.addEventListener(“event”,c);

    o.broadcast();

    // Output
    c
    c
    a

    Also worth mentioning is that AsBroadcaster is built into the player so there is a a slight performance gain and less overhead. In regards to the removeListener bug it has been fixed for flash player 7 but there is another bug similar to the one in EventDispatcher. Basically you can’t remove a listener that has not been called yet:

    o = new Object();
    AsBroadcaster.initialize(o);
    o.broadcast = function(){
    this.broadcastMessage(“event”);
    }

    var a = new Object();
    a.event = function(){
    trace(“a”);
    o.removeListener(c);
    }
    var b = new Object();
    b.event = function(){
    trace(“b”);
    }
    var c = new Object();
    c.event = function(){
    trace(“c”);
    }

    o.addListener(a);
    o.addListener(b);
    o.addListener(c);
    o.broadcast();

    -erik

  2. This is exactly why I don’t write a book. I get free QA, and a “living” document that improves itself via the community. ++Score;

  3. Dear Jesse,

    While you’re summarizing event models, let me add my perspective which is a slight takeoff of the approaches.

    First, for my components, I like to specify the first listener as a property of the component, so it’s very easy to set. Since that is coming in as a string, this mechanism makes the evaluation of the listener at the event-generation time, as opposed to all the other mechanisms that have the evaluation at addEventListener time. For kicks, I also permit the user to specify absolute and relative paths, e.g., using _parent, _level, _root, etc. All this is described at http://flashsim.infopop.cc/eve/ubb.x?a=tpc&s=768608087&f=1106035535&m=7666077455

    The second modification I make with my components is to add a property for the event name. This way, one can change the event names if you need to avoid a clash (for example, two different components sending the same onChange event). You could use a proxy listener, as Mike Chamber implemented, but I think it is easiest to have this capability built into the component properties, although it does clutter the properties when you have a lot of events.

    -jonathan

  4. Hey Jonathan, just had a quick look at your FMXI files and didn’t see a way to specify the scope for the handler e.g.

    foo.addListener(“method”,this);

    BTW Jesse big ups on the formatting of your articale.

  5. Dear Erik,

    Sorry for the omission. The scope is the timeline on which the component is placed, for example, if you put the component on the timeline within mc1.mc2, and specify “xyz”, then it looks for “mc1.mc2.xyz.” If you specify the listener as “_parent.xyz”, then it looks for mc1.mc2._parent.xyz, or mc1.xyz.

    The downside is that it won’t by default access _global without specifically saying _global.xyz, but of course someone could make that change if he or she were doing that sort of thing.

    -jonathan

Comments are closed.