If you have been following/using as3flobile, I just recently committed an update for v0.3 to github. The new version now utilizes as3-signals by Robert Penner for assigning delegate handling.
In the previous versions of as3flobile, interface delegates were used in order to notify subscribing clients of a change to a control. I knew i did not want to institute event dispatching in as3flobile because it was faster to notify a client through a method than going through an observer. So interface delegates were originally used. In basic terms, each control in as3flobile declared one or more optional delegates whose method(s) would be invoked when a change to the control had occured. As an example, this was the now deprecated IButtonDelegate:
public interface IButtonDelegate { function buttonTapped( button:Button ):void; }
When a client wanted to subscribe as the delegate for a tap gesture on the Button, it would point itself as the delegate for the Button:
var button:Button = new Button(); button.delegate = this; addChild( button ); public function buttonTapped( button:Button ) { trace( "button tapped: " + button ); }
I had some issues with this, but i went ahead with that implementation for the first couple versions of as3flobile. As far as how this solution stacked up:
Pros:
1. No event system. Faster execution.
Cons:
1. Only one subscribing delegate allowed.
2. No @optional interface method declarations. A delegate had to strictly adhere to the interface and declare all the methods whether or not it cared to handle them.
So the one Pro was good, but the 2nd Con really started to bother me. In some cases i started adding multiple delegate properties to a control so they could target different changes to the control. Take for instance a delegate for the scroll of a list and a delegate for the selection of a list. It started to feel cumbersome.
Then last week, i finally decide to see what as3-signals was about. Very intuitive and an excellent library. I was impressed and decided that as3-signals was a perfect fit for the delegate handling in as3flobile. So the library has moved to support that. More information is available at as3flobile on github and its wiki.
As with every project i create that has a dependency on another library, there are now two flavors of the build: Standalone and External. The Standalone is meant as a standalone library with the parts required of the dependency compiled in. The External is solely the as3flobile bits and any personal project using the External library will also need to build against the as3-signals library. The as3-signals library can be found on github.
Subsequently, the as3flobile-air and as3flobile-android extensions have been updated due to this change.
So, a big change, i know. But I think a step in the right direction. If you are using as3flobile, update and let me know how you feel about this change.



Quite interesting! Even more with Signals.
Looking through the changes, first signal I came across was in Button. Curious, why did you use DeluxeSignal and GenericEvent for tap? Are you using DeluxeSignal bubbling? Are you using the currentTarget and target properties in the event? If not, you can stead use the lighter Signal class with an empty dispatch().
Looking through the changes, first signal I came across was in Button. Curious, why did you use DeluxeSignal and GenericEvent for tap? Are you using DeluxeSignal bubbling? Are you using the currentTarget and target properties in the event? If not, you can stead use the lighter Signal class with an empty dispatch().
Hi Robert,
In some places i went with DeluxeSignal. The reason usually being so one could access multiple properties that may be of interest (ie. DropDown’s selectionItem or selectedIndex).
The other reason, as is the case with Button, is that I had deemed the control as one that might be used in quick prototyping. Multiple instances dropped on the display list with a single handler to determine the operation (like a large control panel). I originally had them all as Signal and in some cases was doing:
buttonTapped = new Signal( Button );
thoughts on that? is that kosher?
In any event, its at points a little tough trying to figure out how people are going to use these and drumming up the correct API. So i figured i go with the lowest common denominator (familiar event) in places.
I’ve been a big fan of Signals in place of the event model… I’m pleased to see this addition to as3flobile, which I’m about to spend more time to get acquainted with.