Should I use Flash Player’s events or AS3 Signals?

Flex comes with a uses well-designed and extensible event model that’s based on the standard Flash Player’s events. On the other hand, there is an open source alternative solution created by Robert Penner, a well-respected software developer. The replacement is called AS3 Signals. Below are some quick notes comparing standard Flex events with AS3 Signals. I’d appreciate if the readers could add more pros and cons to this laundry list for the benefits of the Flex/Flash community.

• There is no need to instantiate each signal, whereas creation of new instances is required with Flex events (the DynamicEvent is an exception, see the following blog for a sample use).
• AS3 Signals are more strongly typed than events, which seems to be appealing to software developers with Java background, but signals still would not indicate data-type errors during the compile time – they’d produce an error during the runtime only, which is not a big advantage.
• Using AS3 signals makes sense in the applications where lots of events are being dispatched in the background, e.g. a real-time trading application or a game with heavy use of animations.
• AS3 signals have less overhead than events, for example, not every application needs the support of events during the event capture stage, and such a standard feature as event bubbling? Custom Flex events must extend the class EventDispatcher, but with signals you can use composition vs. inheritance.
• AS3 signals support adding a signal listener for one time processing. The function addOnce() will trigger the event once and there is no need to remove listeners as there may be with Flex events.
• With signals you can dispatch many arguments of different data types. This sounds like an advantage, but with signals changing the API in related classes can mean changes in the signal processing code, which is not the case with events that are dispatched with a payload in a form of a DTO.
• While Flash Player events are the part of the Flex framework, AS3 Signals is a third-party product that can be considered as yet another moving part in already long laundry list of the software products contributed to your product by various vendors.

To summarize, I’m neutral to the use of AS3 signals at this point. Would appreciate if someone would contribute compelling arguments for the use of this light-weight and simple to use addition to the toolbox of Flex and ActionScript developers working on enterprise RIA.

Yakov Fain
P.S. AS3 Signals don’t have to be used with any particular Flex-based framework as some people seem to believe. Hint: the name of this framework starts with R and refers to the limbs of a non-human being.

11 thoughts on “Should I use Flash Player’s events or AS3 Signals?

  1. Nice summary of the pro and cons.

    AS3Signals seems to be useful when your application is event-intensive as it will reduce the overhead of every dispatched event (cloning, bubbling and stuff) but if you need to dispatch hundreds of event as the same time, i would think the application architecture needs to be changed somehow, not the event system.
    What is use the most is event is the habitily to use priorities, modify events on the fly and stop propagation if you like, it’s the best way i found to create modular applications. I believe AS3Signals provide some of these functionnalities with a few tricks (not sure you can do all of them) and i wouldn’t like to have events and signals mixed in my application. I prefer using basic events, it’s also a lot easier to understand for other developpers.


  2. Thanks for pointing out this stuff.
    I’ve just started using Signals, along with robotlegs framework. I admit I really like the way it works. Only con I’d point is the “magic” way of doing things with that kind of framework. I know encapsulation is all about not worrying about the underlying magic. But I like magic I can firmly grasp. :)
    Apart from that, I’m curious of Signals performance. You spelled out the heavily animated game example. Considering the many improvements you have to make for your game to run properly (Double buffering, for starters) I really do wonder if Signal dispatching and handling is faster or slower than the traditional Observer pattern event method. If anyone tried, I’d like to know what came out of it.
    And finally, as Fabien said, and AFAIK as mister Penner pointed out, one application shouldn’t use traditional events and signals at the same time. So most devs out there should wait for the opportunity to start a project from scratch before using Signals.

  3. You do not need to extend event dispatcher to dispatch events, you can manually implement ieventdispatcher. Events are not part of flex, they are part of flash/actionscript. Flex simply provides additional event subclasses.


  4. I tried out Signals for the first time on my last project at work, and i am in love with it. Here are a few reasons:

    – Signals can be part of an interface, this is not possible with events.
    – Events have the nice bubbling function, but in my experience the more you rely on bubbling, and the larger an application gets, it becomes much harder to keep track of events. Signals forces you to stay away from bubbling.
    – The signals removeAll() method makes memory management much easier as you do not have to keep track of which objects listen to it. When you call the removeAll() method, you know that no object is referencing the signal through listeners, and will be garbage collected.
    – Writing a custom event is pretty longwinded, especially if you want that event to be able to bubble. Custom signals are a breeze, basically extend Signal and call super() with whatever datatype you want that signal to use as payload. That’s it!

    Your argument about Events being better than Signals because they are able to use DTO as payloads isn’t, in my view, applicable. Signals most certainly can transfer DTOs too. In fact, that is normally want i do when I need to transfer payloads. That way you can just alter the DTO if your API changes, and the Signal won’t care about that change. You can also, as i mentioned above, subclass a Signal and datatype the signals payload. This will give you a compile-time error if you make a mistake.

    There is one catch though, there is no way, from f.ex outside a class, to know what payload a Signal will send as argument to a signal handler. This will, like you say, only generate a run-time error. However, if one is good at documenting, the payload that is sent can be described. But i prefer this drawback compared to drawbacks of events.

    My two cents

  5. – you don’t have to create a new class to support a signal (unlike custom events)
    – signals can be defined in interfaces
    – a single signal can be injected into multiple objects and shared for communication

  6. Events are good for sort of shared components(classes/utilities/etc…), since events are the native way the observer pattern implemented in flash player and so there won’t be any dependencies. Signals on the other hand are good for the actual app development, especially in conjunction with the R framework =) They could also play well for some other callbacks-intensive (3D, games, …) frameworks imho.

  7. I just wanted to reiterate the most important points stated above:
    – Signals supply typed payloads that are compile and runtime checked. mysignal.dispatch(myDTO);
    – Signals eliminate the error prone boilerplate code needed to make a custom event. simply add your payload type to the super call in the constructor. Done. No repeating properties in your custom clone method.
    – Signals can be added to interfaces with typed payloads. This one alone made me start using them.
    – Signals use sensible defaults instead of the ones supplied by default in Flash
    – Signals clean up after themselves.

    If I could use them for everything I would. In fact the only reason I don’t is so that others can use my code without having signals forced on them.

  8. I too have used Signals on various RobotLegs Projects, but decided to go with regular Events on a Large modular RobotLegs application. This is probably due to my lack of knowledge but I couldn’t see a way of not injecting 15+ signals into the Main Context, but that is probably my failing.

    But I thought it would be worth noting that last week I stumbled onto another alternative Events system on Twitter last week:

    The developer states that it resembles events in C and has a comparison chart of the notification systems available now.

  9. Lots of people talk about signals for performance reasons, but this is rarely the case and more often than not premature optimization.

    The real pro of signals, or any homebrewed event system, is you can inspect to see who all of the listeners are (albeit at run time).

    The pro of events, they are standard fare. This is a big deal, other people will look at your signals code and scratch their heads.

  10. I’ve used signals with robotlegs on a couple of projects now. I still use events as well. Some thing signals do well, such as defining them in an interface, handling typed data, not having to extend signals, using notifications via composition. Even though signals are the rage these days, there times where using events is just simply easier. Good example is a heavily nested UI – bubbling on events just makes sense. Also defining a generic event which takes a custom payload and typing the data gets around writing custom classes every time – it’s not very good OO practice – relies even more heavily on magic strings, but then again sometimes you just need to get the damn thing built. People will argue with me on how wrong I am endlessly, but that’s my pragmatic view on the subject.

Comments are closed.