Step One: Hosting the framework artifacts

The first step towards Maven support is for Adobe to start hosting their releases in a Maven-friendly way. They have admitted that this is on the cards for them, but steered away from specifics. They have two real options here – either they submit their artifacts to Maven Central or they set up and deploy to their own public Nexus. Many of us in the community would like to see the former before the latter. Having AS3/Flex/AIR projects build out of the box without requiring any external repository would be a great start (Maven Central is referenced in every execution via the super POM). Currently while the Flexmojos plugin now lives in Maven Central, we’re still reliant on the community (specifically @velobr) to deploy the latest JARs, SWCs and RSLs to Sonatype.

Nevertheless, if Adobe were to host a Flash artifact repository, it could become the central repository for the community to deploy their own open source libraries. This could include tools such as unit testing libraries (FlexUnit, ASUnit), mocking tools (Mockolate, Fluint), micro-architectures (Robotlegs, Parsley), utilities (as3corelib, AS3Signals, RxAS), etc. This would then be the go-to for all Flash developers new to Maven. And, we could finally answer the question plaguing all Maven/Flash newbies: Where are my dependencies???

Step Two: Either sponsor, fork or replace Flexmojos

The next step is for Adobe to decide what to do with Flexmojos – the open source Maven plugin that compiles Flash artifacts. Because it’s open source, they don’t want to usurp the hard work of the community and completely take it over as-is. As I see it, they can either fork it in its current state, sponsor it with funding and their own development team, or start again from the ground up and target Spark and above. In its current state, Flexmojos 4 (4.0-RC2 is the latest) is well equipped to deal with the needs of Flash projects up to and including Flash Player 10.3 (albeit with some bugs). Going forward however, we have no assurance that Flex 4.6 or AIR 3 will be supported out of the box, and I have doubts that the community alone will keep the pace.

Moreover, many of us Flash/Maven advocates are in enterprise development and find it hard enough to convince our customers to rely on an open source initiative that isn’t maintained by Adobe, let alone officially supported or sponsored. If Adobe get behind a Maven plug-in and put their stamp on it, we’ll have a much easier time advocating it to our clients.

Step Three: Integrate with Flashbuilder

Last but not least, is Flashbuilder (FB) integration. The current situation is fairly dismal. Flexmojos 3.9 was the last to officially support the flexbuilder/flashbuilder goal – the process which generated the project structure in Eclipse from your POM (creating and configuring .project and .actionScriptProperties among others). It’s been removed from Flexmojos 4 and there is currently no robust way to keep FB abreast of the latest changes in your POM. You can run the old 3.9 goal for partial results in FB 4.5, but it’s more hassle than it’s worth. Keeping large teams in sync across a complex project is cumbersome at best (and don’t get me started on checking in .project files).

While m2eclipse – the Maven-Eclipse plugin – provides the functionality required to run Maven within Flashbuilder, it is not integrated with the Flexmojos plugin. Put simply, m2eclipse is a lot less powerful with Flashbuilder than it is with typical Java projects in Eclipse. Updated your POM with a different Flex SDK, added some dependencies or a new runtime module? Fine, just make sure to tell all the developers to update their workspaces manually – otherwise either switch to IntelliJ or wait for Flashbuilder 5 (we hope).

Looking forward

The first step in a long process has begun. Adobe are taking the plunge into Maven compatibility and it seems the Flashbuilder team are our best hope for the future of the union. We know support is coming, but how exactly it will pan out is still up for debate. Hopefully we’ll have an answer before the end of the year, but I won’t be holding my breath.

The latest

Want to keep abreast of the latest developments, here’s a list of people to follow:

• Adam Lehman, PM for Flashbuilder, Adobe @adrocknaphobia
• Andrew Shorten, GPM of Dev Tools, Adobe @ashorten
• Raghu Thricovil, one of the new PMs of Flex, Adobe @rthricov
• The Flexmojos plugin @flexmojos
• Marvin Froeder, Flexmojos creator @velobr
• Me @justinjmoses

Summary of additions

• ISlot.applyTo(value:*):void
• ISlot.doesApply(value:*):Boolean
• SlotList.filterNotAppliesTo(value:*):SlotList
• SlotList.findNotAppliesTo(value:*):SlotList

Summary of modifications

• IOnceSignal.removeAll(appliesTo:* = null):void

Details

This backwards compatible addition to as3-signals chiefly allows the removal of all listeners for a given instance or class type. It keeps the convenience of the removeAll function but provides a mechanism to prevent removal of listeners not bound to the current instance or class.

The removeAll() method allows for an optional parameter which will then removeAll slots that applyTo the given parameter, if any.

Essentially, this allows us to asynchronously clean up after a class or instance without affecting any listeners from other classes and without having to define our anonymous functions or closures.

Reasoning

A signal – as a promise – may be reused across instances and classes. For example, a service that is managed by an IOC container may cache signal calls, or a model may use signals to notify of changes. When the signal is shared across various types (either directly via the IOC container, or indirectly cached within an instance) we don’t want to removeAll() lest we remove functional code in other classes (that may well have been written by other developers).

Example

Update Sept 23: Changed the example to use Robotlegs and Mediation

Let’s look at an example to follow this through. This example below illustrates usage when marshalling updates of a model to a view (using covariant mediation to an interface) via a Mediator. Chiefly, the problem arises when an asynchronous cleanup method is called (in this case `onRemove()`), it needs to remove all of the listeners applied to by this instance but not remove listeners that may be used elsewhere.

public class LogModel
{
	protected var updateSignal:ISignal;
	protected var logs:Vector.<LogItem>;

	public function get update():ISignal
	{
		return updateSignal ||= new Signal();
	}

	public function set logs(collection:Vector.<LogItem>):void
	{
		logs = collection;
		update.dispatch(logs);
	}
}

public class SomethingMediator extends Mediator
{
     [Inject]
     public var model:LogModel;

	 [Inject]
	 public var view:IDoesSomething;

     override public function onRegister():void
     {
        model.update.add(function(collection:Vector.<LogItem>):void
		{
			view.logs = collection;
		}).applyTo(this);
     }

     override public function onRemove():void
     {
          model.update.removeAll(this); //removes all listeners applied to this instance only
     }
}

Usage (pseudo-code):

//setup values
const logModel:LogModel = new LogModel();
injector.mapValue(LogModel, logModel);

//map interfaces to a mediator
mediatorMap.mapMediator(IDoesSomething, SomethingMediator);
const viewA:IDoesSomething = new DoesSomething();
const viewB:IDoesSomething = new DoesSomething();

//register mediators for our views (creates two instances of SomethingMediator)
mediatorMap.registerMediators(viewA);
mediatorMap.registerMediators(viewB);

trace(logModel.update.numListeners); //2 - one listener from viewA.onRegister() and one from viewB.onRegister()

mediatorMap.removeMediators(viewA);

trace(logModel.update.numListeners); //1 - one listener from viewB.onRegister()

mediatorMap.removeMediators(viewB);

trace(logModel.update.numListeners); //0

What are closures?

Many people think of closures as anonymous functions – probably because that’s the common form they take – but they are more than that. They are scoped, inline functions that provide a “closure” over a collection of free variables (within the function scope).

Check out the Wikipedia entry on closures..

Why use them?

• They allow the hiding of state (negating the need for maintaining async state in the class) as each closure defines its own variable scope that are available to all nested closures; and
• Because they’re easier to follow than continually jumping to functions defined at a type-level.

Take a peek

In the below example, we have two closures – the first defines the userEvent property and someVariable, the second adds to that with it’s own scope of serviceEvent. You see how the inner closure has access not only to that state within itself, but also to that of the outer closure, as well as that of the init() function AND the class itself. Welcome to the scope chain. Read the AS3 docs on Function Scope.

public class SomeClass
{
	protected var view:ISomeView;

	public function init():void
	{
		var functionSaysSo:Boolean = true;

		userAction.addEventListener(UserEvent.LOGIN,
			function(userEvent:UserEvent):void
			{
				//this is outer closure 

				//define a variable in the outer closure's scope
				var someVariable:String = "something";

				service.addEventListener(ServiceEvent.RESULT,
					function(serviceEvent:ServiceEvent):void
					{
						//this is the inner closure

						if (functionSaysSo)
						{
							view.notify(userEvent.username, serviceEvent.result, someVariable);
						}
					});

				//async call
				service.start(userEvent.username, userEvent.pass);

			});
	}
}

Tip: If you find yourself contesting the readability assertion from before, don’t fret – it’s early days.

Cleaning up after yourself

Like any listener, using a closure as an event listener can create memory leaks if not properly cleaned up. Luckily, we have a few options up our sleeves to avoid this.

Use weak references? [Short answer: no]

Clean, simple and easy, we could simply add closures as weak references.

userAction.addEventListener(UserEvent.LOGIN,
	function():void
	{

	}, false, 0, true);

This keeps the code trim, however it introduces its own problems. If the variable you are listening to lives (is scoped) within another closure or a function definition, it will get cleaned up after the function completes (and before the event might fire). Without a strong reference to that variable, it is a target for garbage collection and you will end up with unpredictable results.

For example, in the following, there is nothing holding onto the timer instance to ensure after the function ends (and before the timer completes) that the timer will still exist and dispatch the TIMER_COMPLETE event.

public class SomethingWeak implements IDoesSomething
{
	public function doSomething():void
	{
		var timer:Timer = new Timer(1000,-1);

		//WARNING! Nothing is holding a reference to timer - GC candidate
		timer.addEventListener(TimerEvent.TIMER_COMPLETE,
			function(evt:TimerEvent):void
			{
				//something happened!
			}, false, 0, true); 

		timer.start();
	}
}

1. Name your handlers

To improve on this, simply define your handlers locally, and you can remove them within your listeners:

» Aug 30: Updated to inline definition

public class SomethingNamed implements IDoesSomething
{
	public function doSomething():void
	{
		var timer:Timer = new Timer(1000,-1);

		var timerHandler:Function;

		timer.addEventListener(TimerEvent.TIMER_COMPLETE, timerHandler = function(evt:TimerEvent):void
		{
			//something happened!

			//cleanup after ourselves
			timer.removeEventListener(TimerEvent.TIMER_COMPLETE, timerHandler);
		});

		timer.start();
	}
}

2. Use arguments.callee to remove them during execution

Even better, we can take advantage of a little known feature in AS3 called arguments.callee, and not even have to name our function:

public class SomethingCallee implements IDoesSomething
{
	public function doSomething():void
	{
		var timer:Timer = new Timer(1000,-1);

		timer.addEventListener(TimerEvent.TIMER_COMPLETE,
			function(evt:TimerEvent):void
			{
				//something happened

				//cleanup after ourselves
				timer.removeEventListener(TimerEvent.TIMER_COMPLETE, arguments.callee);
			});

		timer.start();
	}
}

3. Use type-level handlers to remove from separate call

Alas, what if you need to clean up based on another method or event later in the piece (say when a mediator is disposed)? You’ll need to define your handler at a type-level to retain a reference of it:

» Aug 30: Updated to inline definition

public class SomethingDisposable implements IDoesSomething, IDisposable
{
	//handler is now defined at a type (class) level
	private var timerHandler:Function;

	//we have to also scope the timer to the type level in order to remove listeners
	private var timer:Timer;

	public function doSomething():void
	{
		timer = new Timer(1000,-1);

		timer.addEventListener(TimerEvent.TIMER_COMPLETE, timerHandler = function(evt:TimerEvent):void
		{
			//something happened!
		});

		timer.start();
	}

	public function dispose():void
	{
		if (!timer) return;

		timer.removeEventListener(TimerEvent.TIMER_COMPLETE, timerHandler);

		//for completeness sake
		timer.stop();
		timer = null;
	}
}

At this point, you may be wondering why bother with a closure, when you could simply define the handler as a private method? In this particular example, there is no difference unless you wanted the handler to access the timer instance itself in the handler.

4. Use Signals

There is a final alternative – use the as3-signals library. AS3 Signals is a library that provides an alternative to using Flash Events within your APIs. Using Signals, there are a handful of alternatives to clean up after your closures. Every signal implements ISignal, and it’s that interface we’ll focus on.

ISignal.addOnce()

ISignal.addOnce() prescribes attaching a handler which is called once when the signal dispatches and is removed immediately. Below we use a NativeSignal to wrap the TimerEvent.TIMER_COMPLETE, allowing us to avoid attaching and removing event listeners ourselves. We also now return a Signal which gives the user of the class a strongly-typed signal to what they expect.

public class SomethingSignalsAddOnce implements IDoesSomethingWithSignals
{
	public function doSomething(index:int):ISignal
	{
		//create a Signal to return
		const response:ISignal = new Signal(int);

		const timer:Timer = new Timer(index * 100,-1);

		//create a signal from the Timer event
		const signal:NativeSignal = new NativeSignal(timer, TimerEvent.TIMER_COMPLETE, TimerEvent);

		//once TIMER COMPLETE has occurred, we can dispatch our signal - ISignal.addOnce() ensures that any listeners to Timer will be cleaned up
		signal.addOnce(function(evt:TimerEvent):void
		{
			//tell response that something happened (as opposed to dispatching an event, we dispatch the signal)
			response.dispatch(index);
		});

		timer.start();

		return response;
	}
}

This is often very useful, but not always optimal. We may not always want to listen only once – say if we need to selectively remove the listener based on certain conditions. Sometimes we may only want to remove the listener based on another asynchronous event (as in #4 above).

Signals and arguments.callee

Alternatively, we could use the arguments.callee property and do a conditional remove when required (after 5 ticks in the below example):

public class SomethingSignalsCallee implements IDoesSomethingWithSignals
{

	public function doSomething(index:int):ISignal
	{
		//create a Signal to return
		const response:ISignal = new Signal(int);

		const timer:Timer = new Timer(100);

		//create a signal from the Timer event
		const signal:NativeSignal = new NativeSignal(timer, TimerEvent.TIMER, TimerEvent);

		var numTicks:int = 0;

		signal.add(function(evt:TimerEvent):void
		{
			if (numTicks++ == 5)
			{
				response.dispatch(index);
				signal.remove(arguments.callee);
				timer.stop();
			}
		});

		timer.start();

		return response;
	}
}

You might wonder if you can use arguments.callee within nested closures – and the answer is yes. Just be aware that each closure has its own definition of the arguments.callee, and it overrides the value from any outer closures.

ISignal.removeAll()

ISignal also expose the convenience method: removeAll(). This can help us when we need to remove listeners in response to another method call.

public class SomethingSignalsRemoveAll implements IDoesSomethingWithSignals, IDisposable
{
	private var timerSignal:ISignal;
	private var timer:Timer;

	public function doSomething(index:int):ISignal
	{
		//create a Signal to return
		const response:ISignal = new Signal(int);

		timer = new Timer(500);

		//create a signal from the Timer event
		timerSignal = new NativeSignal(timer, TimerEvent.TIMER, TimerEvent);

		timerSignal.add(function():void
		{
			response.dispatch(index);
		});

		timer.start();

		return response;
	}

	public function dispose():void
	{
		timer.stop();
		timerSignal.removeAll();
	}
}

Be careful using removeAll() – if your class aggregates the signal as above, and it never leaves the containing type, fine. However, there may be occasions when you pass a signal around between various classes (as we do with the response signal above). In these classes, using removeAll() could present unwanted results if one developer inadvertently removes listeners that another class attached.

Conclusions

Whichever way you use closures, you need to remember to clean up after yourself, less you end up leaking memory in the Flash player. Asynchronous programming is here to stay (take node.js and Reactive eXtensions for .NET as examples) and we’re lucky that Actionscript – built on ECMA – supports it natively. As long as you’re aware of the consequences of attaching inline handlers, you can use closures and the async model in general to design a different approach to solving common asynchronous problems. While it takes a little getting used to, I wholeheartedly recommend giving it a shot – you might just like it.

In this post, we’re going to look at how the variance utility for Robotlegs allows mediation against interfaces rather than concrete classes. Apart from the gains in decoupling, we can mediate purely against behaviours, rather than specific implementation. And, as we’re talking interfaces, a UI component can implement as many interfaces (behaviours) as it likes!

• Shout out to Paul Taylor for the inspiration of this post.

Libraries used in this post:

• Robotlegs v1.5.2
• Robotlegs Variance Utility v1.1
• As3-Signals v0.9-BETA

Why use mediation at all?

Mediation is a design pattern that performs the job of managing communication between parts to decouple logic. In terms of modern MVC frameworks, mediators are typically employed to monitor UI pieces from the outside in, so that the UI has no references to the framework whatsoever. The common alternative is the Presentation Model pattern (PM) that typically involves injecting in one or more presentation models to the UI component. As such, the UI component is thus coupled to the particular PMs it uses. That said, when mediating against classes (rather than interfaces, which we’ll get to), we couple the mediator to the UI, which is suboptimal.

Why Robotlegs?

Robotlegs (RL) is a lightweight (50KB) and prescriptive library for MVCS applications. Out of the box it provides us with Mediation, IOC container and Dependency Injection via the familiar [Inject] metadata (thanks to SwiftSuspenders).

Regular (invariant) mediation

Take some UI component: (SomeComponent.mxml)

<s:VGroup>
    <fx:Script>
        //the mediator will tell me when something happens
        public function asyncReturned():void
        {
            //something happened!
        }

        private function onClick(evt:MouseEvent):void
        {
            //tell whoever's listening to do something
            dispatchEvent(new ControlEvent(ControlEvent.START));
        }
    </fx:Script>

    <s:Button label="Start" click="onClick(event)" />
</s:VGroup>

A mediator for this component might look like (SomeComponentMediator.as):

public class SomeComponentMediator extends Mediator
{
    [Inject]
    public var view:SomeComponent;

    [Inject]
    public var service:ISomeService;

    private var viewHandler:Function;
    private var serviceHandler:Function;

    //called when UI component is added to stage and mediator assigned
    override public function onRegister():void
    {
        //handle control events responding
        viewHandler = function(evt:ControlEvent):void
        {
            serviceHandler = function(evt:ServiceEvent):void
            {
                //some where later on tell the view it is done...
                view.asyncReturned();
            }
            service.addEventListener(ServiceEvent.COMPLETE, serviceHandler);

            service.doSomething();
        }

        //attach the listener
        view.addEventListener(ControlEvent.DO_ASYNC, viewHandler);
    }

    //called when UI component is removed from stage, prior to mediator being destroyed
    override public function onRemove():void
    {
       service.removeEventListener(ServiceEvent.COMPLETE, serviceHandler);
       view.removeEventListener(ControlEvent.DO_ASYNC, viewHandler);
    }
}

Via the ADDED_TO_STAGE event, Robotlegs wires up an instance of a mediator for each UI component it finds. All that it requires is that you map in the mediator:

IMediatorMap.mapMediator(SomeComponent, SomeComponentMediator);

Don’t like extending base classes or want your own implementation of mediation? No problems just implement IMediator instead.

So why covariance?

Because there are some problems here with mediating directly to views:

• A UI component can only have one mediator;
• The mediator is tightly coupled to the UI control.

So, what if we wanted to map to an interface instead? We could include the Robotlegs Variance Utility (as a library to our project), and tweak our mediator mapping call to:

IVariantMediatorMap.mapMediator(ISomeComponent, SomeComponentMediator);

The above example becomes:

<s:VGroup implements="ISomeBehaviour">
	<fx:Script>
		//the mediator will tell me when async returns
		public function asyncReturned():void
		{
			//something happened!
		}

		private function onClick(evt:MouseEvent):void
		{
		     //tell whoever's listening to do something
		     dispatchEvent(new ControlEvent(ControlEvent.START));
		}
        </fx:Script>

    <s:Button label="Start" click="onClick(event)" />
</s:VGroup>

Using this interface:

[Event(name="startAsync",type="ControlEvent")]
public interface ISomeBehaviour
{
	function asyncReturned();
}

And the mediator becomes:

public class SomeComponentMediator extends Mediator
{
    [Inject]
    public var view:ISomeBehaviour;

    //... (as before)

}

And voila – we’ve solved both problems in one fell swoop! A UI control can implement as many interfaces as it needs, and our mediates now mediate against a behaviour rather than a concrete UI piece.

So now what?

There’s still room for improvement. Flash has no way to enforce that the class – SomeComponent – will actually dispatch the ControlEvent. If we’re writing these interfaces – these behaviours – we want a contract that explicitly states which events should be fired. Better yet, we’d like the option to state if these events are a functional level or a type level.

Enter Signals, stage right

Signals provide an alternative to events. They are designed to be used within APIs and class libraries, rather than replacing events altogether (Flash events are well suited to UI hierarchies). Where events fire and are handled at a type (class) level, signals live at the variable level. Not only can we pass them to and return them from methods, we can also enforce their presence in types that implement our interfaces. Check out an earlier post on Signals.

By including the lightweight Signals SWC, we have access to the ISignal contract and some common implementations.

Our interface from before now becomes:

public interface ISomeBehaviour
{
    function asyncReturned();

    function get start():ISignal;
}

Our view becomes:

<s:VGroup implements="ISomeBehaviour">
    <fx:Declarations>
        <signals:Signal id="startSignal" />
    </fx:Declarations>

    <fx:Script>
        //the mediator will tell me when something happens
        public function asyncReturned():void
        {
            //something happened!
        }

        //provide access to the type-level signal
        public function get start():ISignal
        {
            return startSignal;
        }
    </fx:Script>

    <!-- Here we actually send the message to the mediator -->
    <s:Button label="Start" click="start.dispatch()" />
</s:VGroup>

We actually now have a property start, exposed from the view that implements the interface, that we can attach and remove handlers to in our mediator.

And so our mediator finally becomes:

public class SomeComponentMediator extends Mediator
{
    [Inject]
    public var view:ISomeComponent;

    [Inject]
    public var service:ISomeService;

    private var serviceSignal:ISignal;

    override public function onRegister():void
    {
        //handle control events responding
        view.start.add(function():void
        {
            serviceSignal = service.doSomething();

            serviceSignal.add(function():void
            {
                //when the service returns, notify the view
                view.asyncReturned();
            });
        });
    }

    override public function onRemove():void
    {
        serviceSignal.removeAll();
        view.start.removeAll(); //clean up any listeners
    }
}

So what now?

Grab the code on Github and have a play around. For ease of use, I’ve included the dependencies along with the source.

The talk starts off discussing Maven, the hierarchical structure of projects, POMs and the build life cycle. We then discuss the Flexmojos plugin to build Flex applications. After that, we talk about repositories – both local and remote, and discuss how Nexus can perform the role of remote repository within your organisation, proxying to others on the web.

We work through 6 main examples. All code is on Github.

1. The simplest application possible – a custom Hello World that uses the latest Flexmojos (4.0-RC1) and Flex SDK (4.5.1)
2. Adding automated unit tests to the build
3. Installing custom dependencies that aren’t hosted on the web
4. Using the Flasbuilder goal to create a Flashbuilder project from a build script
5. Starting Flex applications from the supported archetypes (templates)
6. A basic application that has custom dependencies and its own class library.

Source files: https://github.com/justinjmoses/flexmojos-introduction

Simple. The event system in AS3 is both limited and antiquated. True, native AS3 events offer a convenient way of messaging (bubbling) withinUI hierarchies. Yet, at an abstract API level, they more often as not restrict the developer than aid them.

Chiefly, what Robert Penner has done with as3-signals is create a way to represent events as variables, rather than as magical strings firing off at the type (class) level. It sounds simple. It is. Yet the implications for your architecture is vast.

Consider the following interface of asynchronous methods:

public interface IServiceStream
{
  function open():void;
  function close():void;
}

Now, as the contract is asynchronous, we’ll need some events to notify us when methods have completed. Let’s say we have the following events:

• OPENED
• CLOSED
• ERROR
• TIMEOUT

In keeping with the native AS3 model, the best we can hope for is using the following metadata at the type level:

[Event(name="streamOpened",type="...")]
[Event(name="streamClosed",type="...")]
[Event(name="streamError",type="...")]
[Event(name="streamTimeout",type="...")]
public interface IServiceStream
{
 //...
}

There are four problems with this approach:

1. Decorating via metadata does not enforce that implementors of the interface actually dispatch these events.
2. We should, for completeness, define the events somewhere as static constants. This means we can no longer simply write interfaces, and need to write event implementations and deploy them with our API;
3. We’re using magic strings, and as there is no compile-time checking of the metadata, we’re opening ourselves up to illusive runtime errors, if the wrong events are dispatched.
4. There is nothing to specify which events fire when – and which events belong to which method, and which belong to the class itself.

Magic Strings and No Contract

Method vs Type-level Events 

For example:

var service:IServiceStream = new ServiceStreamImplementation(...);

service.addEventListener(ServiceStreamEvent.OPENED, function(evt:Event):void { ... } );
service.addEventListener(ServiceStreamEvent.CLOSED, function(evt:Event):void { ... } );
service.addEventListener(ServiceStreamEvent.ERROR, function(evt:Event):void { ... } );
service.addEventListener(ServiceStreamEvent.TIMEOUT, function(evt:Event):void { ... } );

//later when required
service.open();

Here is where Signals come in. Let’s rewrite the interface using simple signals.

public interface IServiceStream
{
  function open():ISignal;
  function close():ISignal;
}

import mx.rpc.events.ResultEvent;
import mx.rpc.http.HTTPService;

import org.osflash.signals.ISignal;
import org.osflash.signals.Signal;

public class ServiceStream implements IServiceStream
{
	public function open():ISignal
	{
		var signal:Signal = new Signal(Object);

		//do something asynchronously...
		var httpService:HTTPService = new HTTPService();
		httpService.addEventListener(ResultEvent.RESULT,
			function(evt:ResultEvent):void
			{
				//use the closure to access your signal and dispatch it async
				signal.dispatch(evt.result);
			});

		httpService.send();

		return signal;
	}

	//function close();
}

Now, the usage of this implementation can become:

var service:IServiceStream = new ServiceStreamImplementation(...);

service.open().addOnce(function(result:Object):void
{
    //do something with your returned "result"
});

In one fell swoop we fixed all four of the problems with events. We even have the convenience methods addOnce() and removeAll() from the ISignal interface. The former ensures your listener is removed after it is first used, the latter is pretty self-explanatory. If you look even closer, you’ll see we just implemented the Fluent interface for free.

Imagine this in your mediator pattern – your UIs by definition have no reference to their mediator. Now they have a prescribed way of notifying their mediators that something has occurred.

Wait a second. What about those other events?

How do you return multiple items from a regular method call – compose a type for your requirements.

You could write the following signal collection:

public class ServiceSignals
{
	public var open:ISignal = new Signal(Object);
	public var error:ISignal = new Signal(String);
	public var timeout:ISignal = new Signal();
}

and change your interface to:

public interface IServiceStream
{
  function open():ServiceSignals;
  //...
}

Better yet, you could keep your interface and simply conform your Signal collection into an ISignal with a default listener/dispatcher:

public class ServiceSignal extends Signal
{
	var open:ISignal = new Signal(Object);
	var error:ISignal = new Signal(String);
	var timeout:ISignal = new Signal();

	override public function add(listener:Function):ISignalBinding
	{
		return open.add(listener);
	}

	override public function addOnce(listener:Function):ISignalBinding
	{
		return open.addOnce(listener);
	}

	override public function dispatch(...parameters):void
	{
		open.dispatch();
	}

	override public function remove(listener:Function):ISignalBinding
	{
		return open.remove(listener);
	}

	override public function removeAll():void
	{
		open.removeAll();
	}
}

Then you could use it as such:

var service:IServiceStream = new ServiceStreamImplementation(...);

var signal:ServiceSignal = service.open();

signal.addOnce(function(result:Object):void
{
    //do something with your returned "result"
});

signal.error.addOnce(...);

signal.timeout.addOnce(...);

Perhaps you’re not a huge fan of this solution. You may find that the error & timeout signals are type-level events, and you don’t want to have to add handlers for both open() and close(). OK – so what about this implementation?

public class ServiceStream implements IServiceStream
{
	public var error:ISignal = new Signal(String);
	public var timeout:ISignal = new Signal();

	private var _time:int = 30000;
	private var timer:Timer;

	public function open():ISignal
	{
		var signal:Signal = new Signal(Object);

		//do something asynchronously...
		var httpService:HTTPService = new HTTPService();
		httpService.addEventListener(ResultEvent.RESULT,
			function(evt:ResultEvent):void
			{
				//use the closure to access your signal and dispatch it async
				signal.dispatch(evt.result);
			});

		httpService.addEventListener(FaultEvent.FAULT,
			function(evt:FaultEvent):void
			{
				error.dispatch(evt.fault.faultString);
			});

		timer = new Timer(_time,1);

		var timerHandler:Function = function(evt:TimerEvent):void
			{
				timeout.dispatch();
				timer.removeEventListener(TimerEvent.TIMER_COMPLETE, timerHandler);
			}
		timer.addEventListener(TimerEvent.TIMER_COMPLETE, timerHandler);

		httpService.send();

		timer.start();

		return signal;
	}

	//function close();

}

Notice how we define the handler function as a variable so we can remove it in the listener. This is replicating the ISignal.addOnce() functionality. True, we could have used weak event listeners to allow for garbage collection, however this way is closer to our approach with Signals, so we’ll keep it for consistency.

Your implementor could then be used like this:

var service:IServiceStream = new ServiceStreamImplementation(...);

service.open().addOnce(function(result:Object):void
{
    //do something with your returned "result"
});

service.error.addOnce(function(message:String):void
{
    //handle error
});

service.timeout.addOnce(function():void
{
    //handle timeout
});

service.close().addOnce(function():void
{
    //now closed
});

Whichever way you decide, Signals give you the choice you need to make the best decision for your API.

It has to do with conditional breakpoints in FB4. On top of the normal, if x == true conditions, you can use a sneaky comma trick to inject code.

It’s simple, you enter true (1) or false (0) in the box (depending on whether you want the breakpoint to pause execution) and then add any expression(s) you want, separated by commas. The beauty is that these expression(s) is/are evaluated regardless of whether the breakpoint is executed or not. That means you can inject code into a running debug session without stopping to compile and rerun.

There are two main usages I’ve found for this feature:

Inserting Traces

I regularly find myself tracing through asynchronous operations, trying to figure out the order of events and properties at the time. Sometimes (and this evokes one very painful memory) I’m tracking multiple timers and I can’t learn anything from breakpoints, as I need to get an idea of the order of the ticks (and the corresponding events that are firing).

These scenarios make them a perfect candidate for the injected trace. Try this:

FB4 Conditional Breakpoint Dialog: Tracing

Modifying Properties

The other main use-case is the all-too-common scenario when you want to change a property mid-execution. We’ve all been there – myself just today.

FB4 Conditional Breakpoint Dialog: Property Setting

I tried a lot of different approaches and will show three of them.

I also discuss how to use mockito to supply us with mocks in a way that doesn’t interfere with the BDD approach.

You can read it here

More

more

Silverlight 4 not only brings in all these features, but also a pile of others.  Interestingly, they seem to be making a direct pitch against Adobe AIR with many of the features.  The new Elevated Trust Applications feature (for out-of-browser apps), enables a host of features typically reserved for desktop applications: Local file access; Notifications API; Full-screen full-keyboard access; Cross-domain policy-free networking; and Drop targets.  Of course, features aside, the huge advantage of the Silverlight desktop approach over AIR is that there is only one runtime plugin required.

At the speed Microsoft is moving forward with Silverlight, Adobe is going to have to start seriously upping their commitment to the Flash platform if they want to stay at the top of the game.  Up to now, they could always give the argument of Flex being more feature-rich, and the ease of adaptation to the desktop with AIR – with both of these arguments now void, and Microsoft firmly remaining miles ahead in the developer tooling scene, Adobe’s work is cut out.  They still have greater marketplace penetration with Flash player, but that lead is only going to narrow also.

You’ve got to love competition!

A month back a live webcast took place titled ‘Transcending the client experience’ that focused primarily on the use of RIA in financial services and particularly within Morgan Stanley’s Matrix. A recording of the webcast is now available. I offer a small summary of some of the highlights here.

RIA offers a zero footprint in terms of installation effort and supports real time data presentation through simple yet rich user interfaces. It is bringing the business closer to its clients and is more than just technology in that it is solving real world business problems.

The progressive trends are as follows. There is a front-end shift in that applications are now more driven by user experience and design than previously, can represent large amounts of varied and real time data more coherently and concisely and are increasingly beginning to approximate thick clients in that they are stateful and taking on more of the responsibilities of the server side.

Going forward opportunity is seen in adding threading support and mobile device support to Flex and also in migrating the vast amount of legacy applications currently existing to RIA technology. Morgan Stanley’s Matrix received special recognition throughout being one of the largest production Flex applications in the world, if not the largest, at more than six hundred thousand lines of code developed in the timeframe of a year.

[ Recording of the "Transcending the Client Experience webcast", organised by Adobe and Finextra. Participants in this hour and a quarter long session discuss how developers at financial firms use rich Internet application technologies to integrate real-time data, with the delivery of audio, video, reports and rich interactive charts to trading applications.]

[Panel participants: Hishaam Mufti-Bey (Matrix founder and global director at Morgan Stanley), Stephane Malrait (Global Head of eCommerce at Societe Generale), Mark Greenaway (Adobe), Trevor LaFleche (Senior Analyst at Financial Insights). Moderator: Vivake Gupta, Managing Director, Lab49.]

I recently helped a colleague out with an article on Flex vs. Silverlight in the Enterprise.  Both of us have a strong .NET background, and have more recently been heavily involved on a massive enterprise-scale Flex application.  Although I still stand by the original article, I realise it’s impossible to accurately and fairly detail each platforms’ strengths and weaknesses in one post.

So, I plan to start a bit of a series – comparing different user experiences as created with Silverlight and Flex, and hopefully reaching a conclusion on the benefits of each platform, based upon developer experience/efficiency, and of course how the end result meets the original client requirements.

Each post will focus on a technical area that you may find within any enterprise RIA.  Example areas could be video streaming, datagrid customisation, push messaging, theming/skinning, just to name a few.

It’s as much for my own benefit as anyone else’s – in order to deliver the best client experience, you HAVE to know what the best tools or platform are for any given situation!

“Although this range of numbers is enormous, the cost of this range is precision. The Number data type uses 52 bits to store the significand, with the result that numbers that require more than 52 bits to represent precisely, such as the fraction 1/3, are only approximations. If your application requires absolute precision with decimal numbers, you need to use software that implements decimal floating-point arithmetic as opposed to binary floating-point arithmetic.”

Seems to me they’re basically saying that if you have an app where number precision is important, then don’t use Flex. While Flex can create some great looking applications, my impressions are that for financial and LOB applications – Silverlight with the pedigree of C# and the wide range of 3rd party controls and tools should be the first choice.

Update: I’ve just found a 3^rd party library with a simplified implementation of the decimal data type. http://www.fxcomps.com/components.html Naturally Flex is extensible, so it’s possible to solve most problems one way or another.  However it’s nicer to have an out of the box solution where things like this are present without you having to even think about it.

• Decompiles and analyzes the application to identify security issues.
• Identifies insecure code, and deployment setup.
• No need for access to the code
• And it is Free

Definitely worth trying, finally someone creates a tool to address Flash security.

I have seen examples where there has been spent a lot of time developing code to accommodate for this, with the only result that code base has a lot of non production code which can cause bugs and add an overhead to maintenance of the system. In my eyes that would be wrong, test/mock coding is money wasted on valuable time that should be spent on developing features.

So why not use something which already (almost) exist. When you use HTTPServices, you can point to nearly anything that gives you some kind of XML result. Pointing to a static XML file on the server should give you almost the same as pointing to a service which would serve you dynamic XML.

package com.lab49.spike
{
	import mx.core.Application;

	import mx.rpc.AsyncToken;
	import mx.rpc.http.mxml.HTTPService;

	public class StubHttpService extends HTTPService
	{
		public var stubUrl : String = "";

		private function get stub() : Boolean
		{
			var stubParam : String = String( Application.application.parameters[ "stub" ] );

			return stubParam == "true";
		}

		public override function send( param : Object  = null ) : AsyncToken
		{
			if( stub )
			{
				url = stubUrl
			}

			return super.send( param );
		}
	}
}

And when you use it, insert “stub=true” in your url, and add this to your StubHTTPService:

<spike:StubHttpService
	url="http://localhost:8080/spike/myService"
	stubUrl="xml/stub.xml"
	...
/>

The presentation is available on AdobeTV.

Who said Adobe Flex couldn’t be used for critical systems? If Adobe wants Flex to be seen as a serious framework in the enterprise, this is the kind of projects they need to show more of.

Over a series of posts I will cover some of the experiences gathered from this and other projects I have taken part in. There is usually more to a project then just choosing a framework like Cairngorm, PureMVC or one of the many IoC containers which are popping up everywhere.

• ActionScript 2
• ActionScript 3
• C#
• ColdFusion
• haXe
• Java
• Perl
• PHP
• Python
• Ruby

If you have an interest in presentation patterns, I would recommend to look at Paul Williams great presentation pattern blog series. He also has a series covering how to unit test the different patterns, which most developers should find interesting.

Tomorrow I will present “Flex Client Architecture & Best Practices”, where topics like PresentationModel and unit testing will be covered.

As I also announced on 360|Flex Europe in Milan, Adobe Consulting will over the next few months share some of our best practices in a series of articles. A topic could be for example “Cairngorm and Modules”. Steven Webster has posted a call for topics blog post

Presentation Cairngorm Deepdive

In my presentation – Cairngorm deepdive, I’ll be covering some of the history behind the Cairngorm Microarhitecture, how to use it on large scale projects, how to handle security, and also shed some light on the future of the framework.

There is also a second presentation covering Cairngorm, Neil Webb will present Cairngorm for beginners.

If you haven’t already signed up for the conference, you can do so here

Given the asynchronous nature of making service calls in Flex (or Ajax apps or any other RIA technology) you can run into race conditions if you simply fire off all of the service calls at once, especially if the result handler of one service has a dependency on a piece of data that was loaded from a different service. Additionally, you need to be notified of when all the initialization services have finished so you can perform any rendering actions to make the app available for business.
(A concrete example of this would be an app that needs to load a list of position dates from a service, and will then pick the latest position date as a parameter into a number of other service calls that populate DataGrids on the screen. You must defer the calls to load each grid until the positionDates service has returned).

The first approach that my team had to implementing this would be to fire off the first service in the creationComplete handler of the application, then at the end of that service’s result handler fire off the second service, and so on. Given an application with two HTTPServices (svc1 and svc2) declared and a creationComplete event handler to kick the processing off, a contrived example of this would look like this:

private function onCreateComplete(event:Event):void
{

    // wire service result handlers
    svc1.addEventListener(ResultEvent.RESULT, result1);
    svc2.addEventListener(ResultEvent.RESULT, result2);

    // invoke first service
    svc1.send();

}

private function result1(event:ResultEvent):void
{
    // do something with the result of svc1, then invoke
    // svc2
    svc2.send();
}

private function result2(event:ResultEvent):void
{
    // do something with the results of service 2, then
    // perform actions to make app available
}

This type of design quickly grew brittle and unmanageable. Readability is forfeited as you need to navigate around all of your event handling methods to discern the ordering of events. Adding new service calls or changing the order becomes an exercise in figuring out where to insert the next call and how to hook it up into the flow. If you have certain subclasses of your application class that needed additional service calls (as my project does), it is difficult to insert a new service into the flow.

As a piece of refactoring, I created a neat little class to give us an easy way to put the ordering of the services in one central location, decoupling the service flow from the result handlers. It maintains an internal list of services to call, in the order that they are added to the chain. When you add an HTTPService (and it’s corresponding event handler) to the chain, a generic event handler is added to listen for the result event. When this handler is invoked, it’ll call the actual event handler that you provided for that service, and will then pop the next service off the chain and call it. You can also specify a final handler method to be called once all the services in the chain are finished:

public class ServiceChain
{
    private var _chain:Array = new Array();
    private var _curEntry:Object;
    private var _chainFinishedHandler:Function;
    public function ServiceChain()
    {
        super();
    }

    /**
     * @param f
     * Setter for the chainFinishedHandler, a method that will be
     * invoked when the final service has returned.
     */
    public function set chainFinishedHandler(f:Function):void {
	_chainFinishedHandler = f;
    }

    /**
     * @param svc
     * @param resultHandler
     *
     * Adds a chain entry for the HTTPService and resultHandler pair
     * (added as an anonymous object with svcclass and handler
     * properties).  An event listener is added to the svc class to
     * invoke the genericOnServiceResult when the service returns.
     */
    public function add(svc:HTTPService, resultHandler:Function):void
    {
        // redirect the results of all service calls to the generic handler
        svc.addEventListener(ResultEvent.RESULT, genericOnServiceResult);
        _chain.push({svcclass: svc, handler: resultHandler});
    }

    /**
     * Pick the next service off the chain and invoke it's send method.
     * If there is no service on the queue, we are finished.  Invoke the
     * chainFinishedHandler if present.
     */
    public function run():void
    {
        _curEntry = _chain.shift();
        if (_curEntry == null) {
            if (_chainFinishedHandler != null)
                _chainFinishedHandler();
            return;
        }
        _curEntry.svcclass.send();
    }

    /**
     * @param event
     *
     * The service has returned, so invoke the actual event handler for the
     * service, then call run() to pick the next service from the chain.
     */
    private function genericOnServiceResult(event:ResultEvent):void
    {
        _curEntry.handler(event);
        run();
    }
}

Then the application code simplifies to:

private function onCreateComplete(event:Event):void
{
	var chain:ServiceChain = new ServiceChain();
	chain.add(svc1, result1);
	chain.add(svc2, result2);
	chain.chainFinishedHandler = chainFinished;
	chain.run();
}

private function result1(event:ResultEvent):void
{
	// ... do something with the result of svc1
}

private function result2(event:ResultEvent):void
{
	// ... do something with the result of service 2
}

private function chainFinished():void
{
	// make app available
}

We’ve now decoupled the ordering of service calls from the handling of each service result, have a way for subclasses to insert their own calls to the chain (making the chain a protected member), and have an easy way to execute logic when service calls have finished. This pattern I suppose is something akin to a Chain of Responsibility with a different flavor to handle the asynchronicity of each operation. I’d imagine this type of thing could be useful in Flex, Silverlight, or any other rich client app which must initialize itself from remote services called asynchronously.

Both Rails and Flex are considered “best in class” when it comes to rapid development, and during todays 3.5 hour session we will show how Flex can integrate with Rails using a REST based back-end.

The presentation can be found here, and the code is on google code