Several months ago we had a Flex Frameworks roundup at our local Adobe User Group (RMAUG). I presented on the Universal Mind Extensions to Cairngorm and have since had a few requests for more info on the extensions. In this post I will explain my top 5 favorite ways to implement Cairngorm features in a Flash Application built with Flex many including elements from the UM Extensions.
So, without further delay…
5. The AnnounceFaultEvent
Error handling can often be an overlooked item when building a Flex application. The AnnounceFaultEvent class in the UM Cairngorm Extensions provides a nice way to generically handle faults. In fact, the UM implementation of Command has built-in support for the AnnounceFaultEvent. If a FaultEvent is passed to the fault method of the Command (via the IResponder interface), an AnnounceFaultEvent is automatically dispatched through the FrontController.
In a standard Cairngorm implementation a Command instantiates a Delegate and invokes a method on that Delegate to perform the action that the Command is responsible for. Typically, the Delegate will inform the Command that either a result returned form the operation or a fault returned from the operation. Because Flex is based on asynchronous communication the Command‘s call to the Delegate cannot be blocking (ie wait for a response). So, we need a way to signal to the Command that the operation has finished and deliver the result (or fault) of the operation. The common way to accomplish this task is using the Responder pattern. A Responder is a class of object that has both a result and a fault method. The idea is that a caller maintains a reference to the Responder instantiation, and the callee notifies the caller via this object. In the UM Extensions, the Command class will automatically fire an AnnounceFaultEvent when a Delegate passes back a FaultEvent to the Command.
Here’s the example:
AnnounceFaultEventExampleApplication dispatches a AnnounceFaultEventExampleEvent
AnnounceFaultEventExampleEvent is handled by CairngormTipsFrontController
CairngormTipsFrontController instantiates AnnounceFaultEventExampleCommand
AnnounceFaultEventExampleCommand calls exampleOperation on AnnounceFaultEventExampleDelegate
AnnounceFaultEventExampleDelegate responds with a FaultEvent
The FaultEvent is handled by FaultCommand
Tip #4: The EventGenerator is coming soon… It’s out now
Thanks for sharing this Adam. We’re using the UM extensions, but were unaware of this feature. I’m not sure we’ll be able to use this out of the box, however, since we have a multi-window AIR app that needs to pass additional information about which window should get the alert box popping up on it.
Hi Andrew,
Glad you found value in the post. AnnounceFaultEvent is great for standard catch-all error handling. It sounds like your situation may be a bit unique. However, you may be able to add the window ID data on to the mx.rpc.Fault object that belongs to AnnounceFaultEvent. I’m not sure if it makes sense that your delegate would have that window ID reference, but at least this gives you a place to attach some data.
Cheers!
-adam
Another point I didn’t think to mention… You can, of course, manually dispatch the AnnounceFaultEvent and add the specific data you’d like to use for the fault in question. In this scenario, some of your faults may just pass from Delegate to Command automatically, and some could be caught by the Command in a case-by-case scenario where the Command manually dispatches the AnnounceFaultEvent.