Why Robotlegs benefits from AS3-Signals

My problem with using the Event Model and Robotlegs

One of the things that bugs me about the use of the event model with Robotlegs is that Mediators are tightly coupled with the views. Take my Twitter Search Demo for example, the SearchEntryMediator class expects an instance of the SearchEntry class as its view, see below.

One suggestion could be type the view to an interface in the mediator, but this is too loosely coupled because an interface cannot define the events an object can dispatch. There are a few solutions to this issue, for example we could use function callbacks, however Robert Penner has come up with a better solution, AS3-Signals.

The solution: AS3-Signals

Robotlegs and AS3-Signals work really well together, especially with the introduction of the Command Signal Extension. Each of these libraries don’t rely on string constants to function, they are strongly typed, therefore the compiler is able to throw errors much sooner if something is wrong.

A Signal gives an event a concrete membership in a class, for this reason we are able to include Signals in interfaces. Using this the SearchEntryMediator in my Twitter Search Demo can type the view to an ISearchEntry, and any class that implements this interface must include the searchRequested signal, see below.

The interface is very simple and just defines the searchRequested signal.

Why bother?

It’s a good question, why should we go to the effort of creating interfaces for our views? We could quite easily continue to use the Event model with Robotlegs and it would work, but the use of interfaces would be beneficial for a multi-platform Flash application or for a workflow that involved more than one person.

Imagine an application that is to be deployed to many different devices that have various screen sizes, some can use a mouse, some can be touch enabled and some are restricted to keys. To create the best user experience you would want the view of your application, and the interaction with that view, to be tailored to that device. By using interfaces for our views we can use the same code base for all applications but have different views for each device; as long as our views implement our interfaces the application will work. More advantages to this are seen if different people implement the views; by using Signals in the interface the person developing the view must implement them whereas there’s nothing specify that the person must implement an event.

P.S It’s also worth noting that there are many other benefits to using AS3-Signals, for example they provide significant speed improvements over using Events, not just the ability to define them in interfaces.