Feedback wanted: overhauled Event System

Daniel

Hi guys,

I've just added an experimental new feature to the development branch: an overhauled event mechanism. I'd be happy about your comments! Does this make sense? Do you like it / not?

1) Automatic Event Pooling

You can now dispatch events with this line instead of the old one:

object.dispatchEventWith(Event.TRIGGERED, true);

// equivalent to:
object.dispatchEvent(new Event(Event.TRIGGERED, true));

Besides having to type less, this has the advantage of using a pool of event objects behind the scenes. The garbage collector will be happy about that. =)

This only works for instances of "Event", though. But here's where the next change comes in handy:

2) Event Data

The standard event class now has a new property "data" of type "Object", which can contain any value you like. In many cases, this allows you to avoid creating a custom event; a new event type string will do.

addEventListener("customType", onEvent);
dispatchEventWith("customType", false, "testData");

private function onEvent(event:Event):void
{
    trace(event.data); // prints "testData"
}

OK, this is handy, but not a revolution. But the third change is what makes this system extraordinarily handy:

3) Variable Parameters for Listeners

This feature is best shown with sample code:

addEventListener("customType", onEvent);
dispatchEventWith("customType", false, "testData");

// version 1:
function onEvent():void
{
    // I'm not interested in the event object, just that it has happened
}

// version 2:
function onEvent(event:Event):void
{
    // now you can access the event object, too
    trace(event.data); // -> "testData"
}

// version 3:
function onEvent(event:Event, data:String):void
{
     // now you've got all data easily accessible
     trace(data); // -> "testData"
}

Pretty neat, isn't it? That removes a lot of boiler plate code. Look at these examples:

addEventListenerWith(Event.ADDED_TO_STAGE, onAddedToStage);
function onAddedToStage():void
{
    // have you ever used the event here?!
}

addEventListenerWith(Event.ENTER_FRAME, onEnterFrame);
function onEnterFrame(event:Event, passedTime:Number):void
{
    // passedTime is directly available
}

addEventListenerWith(KeyboardEvent.KEY_DOWN, onKey);
function onKey(event:Event, keyCode:uint):void
{
    // in most cases, I don't need anything but the keyCode.
}

That's it!
I'd be happy about your feedback! =)

mrpinc

Definitely like it, certainly removes a lot of redundant code. I tend to use signals most of time but I am all in favor of improving the existing model. Another win for Daniel.

akane

Pretty cool ! I really like it !

danieldourado_2

For sure it is a nice addition.

timrichardsn

Nice! Particularly fond of the variable parameters. Just so I'm clear, if we want to use a custom event, we can "dispatchEventWith("customEvent") and add an event listener using 'addEventListener("customEvent")' unless the event we are listening for is not custom, but an instance of "Event", in which case we can use addEventListenerWith(...). Is that correct?

Jeff

I also like these additions.

Although I know most developers are not normally doing this anyway, it might still be important to clarify in the documentation for Starling Event use that in no situation do you want to hold on to references of broadcasted event instances from Starling since they are immediately put back into a pool and have their attributes cleared and reset as soon as they are used again. Listeners will want to copy/retrieve data from the event instances in their handlers and be done with them.

(technically in the old system one could hold on to a reference of an event instance for later use, but not normally common/good practice)

neoflame

Looks really nice Daniel! I have a question about the event object pooling. Does this apply to EnterFrameEvent which I've been using recently? Or should I switch to this:

function onEnterFrame(event:Event):void
{

}

joshtynjala

I like the event pooling. I had heard that Flash Player can do that with native events, so I was hoping to see you do the same.

For some reason, the "data" property feels a little strange. However, the variable event arguments is great. I love being able to omit the event object in the listener, if I don't need it.

How variable is it? Can I dispatch with an arbitrary number of extra arguments?

dispatchEventWith("customType", false, "testData", 4, "Etc");

function onEvent(event:Event, data1:String, data2:int, data3:String):void
{
}

If not, will you consider it?

Daniel

Hey guys,
thanks for the great feedback! It seems as if that feature is quite popular! =)

Tim, "dispatchEventWith" will create (or pool) an instance of the "Event" class; you can use any custom event *type* (string) with that method, but not custom event *classes* (like "TouchEvent" or "MyCustomEvent", subclasses of "Event").

Jeff, you're right, this has to be clearly documented -- thanks for the reminder!

Neoflame, you can use whatever you like better! When you look at the "EnterFrameEvent" class, I changed it a little so that it saves the "passedTime" in the "data" property of the base class. So you can use both:

function onEnterFrame(event:EnterFrameEvent):void
{
    event.passedTime == event.data as Number;
}

function onEnterFrame(event:Event, passedTime:Number):void
{
    event.data as Number == passedTime;
}

Josh, currently this is fixed for one data parameter. Do you think more would be useful? You'd have to remember (or document) the order of the parameters, as well, then -- personally, I'd prefer doing it like that when I need more data:

dispatchEventWith(Event.TYPE, false, { count: 4, text: "text" });

function onEvent(event:Event, data:Object):void
{
    trace(data.count, data.text);
}

... or create a custom class for the data altogether; sometimes, it might even make sense to stick with the classic system of subclassing the Event class.

MoebiuZ

Useful indeed

Clayton_Grey

I like this! Sounds really smart!

However to make one point of dissent, you're creating another layer of differentiation between AS3 and Starling. By choosing to break from the way AS3 handles events your adding additional knowledge one needs to learn to understand Starling.

One of the reasons I was drawn to it originally is that you patterned it so closely to AS3. "clean" and "convenience" tends to be a slippery slope. The code at the end of that might in fact be very useful; it may be better than traditional AS3 development in many respects, but it becomes specialized knowledge. Sometimes it's better to leave it clunky so that it's more accessible to a broader audience. I'm certain there are things about the ECMA script spec that Adobe thinks is terrible at this point, but they haven't changed AS3 to suit their fancy. With what Starling is going for, I think there's an argument to be made to sticking to AS3 as much as possible.

That said, I would probably go with it! 🙂

thibault.imbert

Hi Clayton,

Good point, it is one of the force of Starling, it looks very familiar the first time you look at it. But to balance your point, the AS3 event model has its flaws too and we may change that in the future. It is a good thing that Starling copies what is good in the runtime but dissociate from what is not the best 🙂

A good example is how popular Signals is today amongst AS3 developers. Especially if those changes help for reducing the GC pressure and as a result performance, I think those changes are great.

Thibault

frisk

It's a good idea to reduce the created objects.
In the underlying architecture of my game, I tried to avoid events and used some sort of notification mechanism which basically works similar to this overhauled event system.

While profiling I saw that a lot of TouchEvent instances have been created.
Any plans of pooling/reusing instances of this class?

Daniel

Yes, those should be pooled as well in the future.

zeeyang

Have you seen this, Daniel. https://github.com/FilipZawada/Fingers

Artemix

Thumbs up for this idea. And if it requires to learn something new/different than previous AS3 common knowledge, so be it 🙂

Nelio

I'm throwing my money at the screen and nothing happens. Oh wait, Starling is free!

(YES, I LIKE IT!)

Daniel

Thanks for the link to "Fingers", Zee! I haven't seen that one before, that's really cool concept. I will definitely check out how the author managed to do that!

Thanks for the feedback, guys!

AV

Sounds like really good stuff and really impressed with Starling.

I haven't looked at the code so this is purely assumption but there must be a minor performance hit when resolving what type of handler is being used isn't there? The as3 Event system is definitely not perfect partly because it was fairly slow, which to me it sounds like it will be even slower having to resolve how many parameters to pass each listener. Object pooling is also great for reducing memory footprint and garbage collecting but as Jeff said this will need to be clearly documented, maybe 'addEventListenerWith' could have a bool parameter 'autoRelease' that defaults to true allowing the event to be recycled once the handler has been called. If false then a new Event would have to be retrieved from the pool for the next handler. Or maybe I'm just a control freak and this won't be used enough to bother with. I honestly can't think of a time I've ever stored a reference to an event object.

With version 3 listener seeing as though the advantage is not having to extend and instantiate an event class, perhaps the first parameter of type Event isn't needed? Especially as version 2 also allows the event and data to be retrieved in case both are needed.

NoriSte

Daniel, I've always subclassed the AS Event class because I need the data object... your work is fantastic, thanks for improve every day the platform!!!