Utilizing separate Responder objects will reduce an applications memory footprint as the Command will immediately become eligible for Garbage Collection in the next sweep once the Commands execute(); implementation returns.

Let me explain. When a Command implements IResponder and instantiates a Business Delegate there is a reference to the command via the delegate and the AsyncToken instance, thus the reference count for the Command is greater than 0 and it will not be deallocated. The Command will only be eligible for garbage collection once the AsyncToken invokes result or fault on the Command and the flow of control is returned.

When using separate Responder objects the memory allocated by the Responder instance will almost always be more efficient as the extra overhead associated in the execute implementation of the Command is not be a part of the Responder.

Hope that clarifies some things.
- Eric

This is very interesting.
What I’ve noticed when using the profiler is that commands that do not implement IResponder get cleaned up by GC.
However commands that use delegates do not.
It seems it may be because of the front controller. Front controller uses weak references but perhaps because the command is used as the responder in the delegates call object, the FrontController never releases it.
If the FrontController is removed these instances are cleaned up.

I was wondering.
If we use Responder objects instead of commands, perhaps after the responders.result() finishes we can remove the reference from the command to the responder there for freeing up the command for gc and hopefully leave a circular reference for the responder and delegate so that they can also be cleaned up.

I will test this later.

Hope my ramblings made sense.

You certainly can use Cairngorm Events and Commands to handle view specific behaviors. Any application level Events should be implemented as higher level Cairngorm Events. So as a rule of thumb, if you are building an application with Cairngorm all application specific Events should be implemented as Cairngorm Events. All low level events should be implemented as generic Events. For instance, if a component needs to communicate with another component, but the interaction only pertains to the components, not the higher level application as a whole, then the Event should just be a generic flash.events.Event and not a Cairngorm Event.

Hope that helps.
- Eric

Invoking another Command from a Responders result would be very easy to implement as all that would be needed would be to pass a reference of the Command to the Responder instance via its Constructor

Thanks,
Almog Kurtser.

Thanks for your comments. I didn’t include the delegate in the example as it is not really needed to illustrate the implementation of a separate Responder.

Thanks,
Eric

You don’t show the Delegate in your post but I assume there’s nothing unusual going on. Are you just setting token.addResponder(responderRef); ?
Cheers, Neil