AS3 Robot Legs and Signals - Using Signals, Pretty Detailed, Any Alternatives?

Question

Im using RobotLegs and Signals for my application. This is my first time I used Robotlegs and Im used the Signal Command Joel Hooks command map here

I noticed that it seems rather verbose, unlike events. For each Signal, I have to create a new class, whereas with events I would group the types of events into one class.

I like how to visually and instantly describe it. Just looking at the signal packet will show all the applications. Although this seems pretty verbose to me.

Other people use it. Do I use signals like this correctly, or have people found a way around this verbosity?

Greetings

Answer 1

This is the right way. The main advantage of signals is that you can include them in interface definitions, but obviously you will get a large pile of signals.

In general, I only use signals for my view-> mediator and service-> command (1 to 1) interfaces. For system notifications, I use events (n-to-n). This makes the number of signals more manageable. But this is a matter of preference, obviously.

Using a good IDE system and / or templates alleviates the big “pain” of having to create different signals.

Answer 2

You do not need to create a new class of signals for command cards, this is just good practice. You can simply set the "dataType" class to the type property and make a switch . But that would be dirty for the teams. But note: the commands are mainly designed to trigger a wide-action application.

Not all signals trigger large-scale application actions.

For example, if you are responding to a bunch of events from one View . I suggest creating a Signal class for related view events (e.g. MyButtonSignal for MyButtonView ) and assigning a type property to it.

A typical signal would look like this:

 package { public class MyButtonSignal extends Signal { public static const CLICK:String = 'myButtonClick'; public static const OVER:String = 'myButtonOver'; public function MyButtonSignal() { super(String, Object); } } } 

Shipping as such

 myButtonSignal.dispatch(MyButtonSignal.CLICK, {name:'exit'}); 

Listen as usual:

 myButtonSignal.add(doMyButtonSignal); 

Handle this way:

  protected function doMyButtonSignal(type:String, params:Object):void { switch(type) { case MyButtonSignal.CLICK: trace('click', params.name); break; case MyButtonSignal.OVER: trace('OVER', params.name); break; } } 

It is sometimes useful to use the data variable as your own data class.

So, every time you understand “Aw shit, I need to respond to another event”, you just go to Signal and add a new static const to represent the event. Much like you (probably?) When using Event objects.

Answer 3

For each Signal I have to create a new class, while with events I will group the types of events into one class.

Instead, you can simply use the signal as a property ... something like:

 public var myCustomSignal:Signal = new Signal(String,String); 

You can imagine a signal as a property of your object / interface.

In Joel’s example, he uses signals to indicate system-level events and compares them with SignalMap robots, which displays signals by type. Since they are displayed by type, you need to create a unique type for each system level signal.