From Farata Systems blog

Event-driven programming model offers an excellent architecture based on loosely-coupled components consuming and throwing events. This simply means that a properly designed component knows how to perform some functionality and notifies the outside world by broadcasting one or more custom events. I need to stress, that such component does not send these events to any other component(s). It just broadcast its “exciting news” the event dispatcher. If any other component is interested in processing this event, it must register a listener for this event.

Before explaining how to create an event-driven component let’s state how we are going to use them.  This is a typical scenario: MyApplication uses Component1 and Component2. Components do not know about each other. Any event-handling component should define this event inside. For example, Component1 dispatches this custom event sending out an instance of the Event object, which may or may not carry some additional component-specific data. MyApplication handles this custom event and if needed, communicates with Component2 with or without feeding it with data based on the results of the first component event.

We’ll create a “shopping cart” application that will include a main file and two components: the first a large green button, and the second one will be a red TextArea field. These components will be located in  two separate directories “controls” and “cart” respectively.

To create our first MXML component in Flex Builder, select the “controls”  directory and click on the menus File | New MXML Component. In the popup screen we’ll enter LargeGreenButton as a component name and we’ll pick Button from a dropdown as a base class for our component. Flex Builder will generate the following code:

<?xml version="1.0" encoding="utf-8"?>
<mx:Button xmlns:mx="http://www.adobe.com/2006/mxml">
    
</mx:Button>

Next, we’ll make this button large, green and with rounded corners (just to give it a Web 2.0 look). This component will be dispatching an event named greenClickEvent. When? No rocket science here -  when someone clicks on the large and green.

Custom event in MXML are annotated within the Metadata tag in order to be visible to MXML. In the listing below,  in the metadata tag [Event] we declare a custom event of generic type flash.events.Event.  Since the purpose of this component is to notify the sibling objects that someone has clicked on the button, we’ll define the event handler greenClickEventHandler() that will create and dispatch our custom event.


<?xml version="1.0" encoding="utf-8"?>
<mx:Button xmlns:mx="http://www.adobe.com/2006/mxml"
    width="104" height="28" cornerRadius="10" fillColors="[#00ff00, #00B000]"
    label="Add Item" fontSize="12" click="greenClickEventHandler()">
    
    <mx:Metadata>
        [Event(name="addItemEvent", type="flash.events.Event")]
    </mx:Metadata>
    
    <mx:Script>
        <![CDATA[
            private function greenClickEventHandler():void{
              trace("Ouch! I got clicked! Let me tell this to the world.");
            dispatchEvent(new Event("addItemEvent", true));// bubble to parent
            }
        ]]>
    </mx:Script>
</mx:Button>

Listing 1. LargeGreenButton.mxml

Please note, that the LargeGreenButton component has no idea of who will process its addItemEvent. It’s none of its business: loose coupling in action!

In dynamic languages following naming conventions. Common practice while creating custom components is to add the suffix “Event” to each of the custom events you declare, and the suffix ”Handler” to each of the event handler function.

Here’s the application that will use the LargeGreenButton component:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
    xmlns:ctrl="controls.*"   layout="absolute">
    
    <ctrl:LargeGreenButton addItemEvent="greenButtonHandler(event)"/>
        
    <mx:Script>
        <![CDATA[
            private function greenButtonHandler(event:Event):void{
                trace("Someone clicked on the Large Green Button!");
            }
        ]]>
    </mx:Script>
</mx:Application>

Listing 2. EventApplication.mxml

We have defined an extra namespace “ctrl” here to make the content of “controls” directory visible to this application.  Run this application in the debug mode, and it’ll display the window below. When you click on the green button it will output on the console the following:

Ouch! I got clicked! Let me tell this to the world.
GreenApplication:Someone clicked on the Large Green Button.  

While adding attributes to <ctrl:LargeGreenButton>, please note that code hints work, and Flex Builder properly displays the greenClickEvent in the list of available events of new custom component button.


 

Figure 1. The output of GreenApplication.xmxl

Our next component will be called BlindShoppingCart. This time we’ll create a component in the “cart” directory based on the TextArea.

<?xml version="1.0" encoding="utf-8"?>
<mx:TextArea xmlns:mx="http://www.adobe.com/2006/mxml"
      backgroundColor="#ff0000"  creationComplete="init()">
        
    <mx:Script>
        <![CDATA[
            private function init():void{
                parent.addEventListener("addItemEvent",addItemToCartEventHandler);
            }
    
            private function addItemToCartEventHandler(event:Event){
                this.text+="Yes! Someone has put some item inside me, but I do not know what it is. \n";
            }
        ]]>
    </mx:Script>
</mx:TextArea>

Listing 3. BlindShoppingCart.mxml

Please note, that the BlindShoppingCart component does not expose to the outside world any public properties or methods. It’s a black box. The only way for other components to add something to the cart is by dispatching the addItemEvent event.  The next question is how to map this event to the function that will process it.  When someone will instantiate the BlindShoppingCart, Flash Player will dispatch  the creationComplete event on the component, our code calls the private method init(), which adds an event listener mapping the addItemEvent to the function addItemToCartEventHandler. This function just appends the text “Yes! Someone has put …” to its red TextArea.

The application RedAndGreenApplication uses that uses these two components LargeGreenButton and BlindShoppingCart.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical"
    xmlns:ctrl="controls.*"   xmlns:cart="cart.*">
    <ctrl:LargeGreenButton addItemEvent="greenButtonHandler(event)"/>
    <cart:BlindShoppingCart width="350" height="150" fontSize="14"/>
    <mx:Script>
        <![CDATA[
            private function greenButtonHandler(event:Event):void{
                trace("Someone clicked on the Large Green Button!");
            }
        ]]>
    </mx:Script>
</mx:Application>

Listing 4. RedAndGreenApplicatoin.mxml

Let’s go through the sequence of its events:
When the green button is clicked, the greenButtonHandler is called and it creates and dispatches the addItemEvent event on itself. The event bubbles to the parent container(s) notifying all listening parties of the event. BlindShoppingCart listens for such event and responds with adding text. Run this application, click on the button, and the window should look as follows:

 
Figure 2. The output of RedAndGreenApplication.mxml

And one more time: the green button component shoots the event to the outside world without knowing anything about it. That is very different from the case when we would write “glue” code like cart.addEventListener(“click”, applicationResponseMethodDoingSomethingInsideTheCart).

Sending Data Using Custom Events

To make our blind shopping cart more useful, we need to be able not only to fire a custom event, but this event should deliver description of the item that was passed to shopping cart. To do this, we’ll need to create a custom event class with an attribute that will store application-specific data.  

This class has to extend flash.events.Event, override its method clone to support event bubbling, and call the constructor of the super class passing the type of the event as a parameter. The ActionScript class below defines a property itemDescription that will store the application-specific data.

package cart {
    import flash.events.Event;

    public class ItemAddedEvent extends Event    {
        var itemDescription:String; //an item to be added to the cart
        public static const ITEMADDEDEVENT:String ="ItemAddedEvent";
        public function ItemAddedEvent(description:String )
        {
            super(ITEMADDEDEVENT,true, true); //bubble by default   
            itemDescription=description;
        }

        override public function clone():Event{
            return new ItemAddedEvent(itemDescription);  //  bubbling support inside
        }          
    }
}
Listing 5. The custom event ItemAddedEvent

The new version of the shopping cart component is called ShoppingCart, and its event handler extracts the itemDescription from the received event and adds it to the text area.

<?xml version="1.0" encoding="utf-8"?>
<mx:TextArea xmlns:mx="http://www.adobe.com/2006/mxml"
      backgroundColor="#ff0000"  creationComplete="init()">
    
    <mx:Script>
        <![CDATA[
        private function init():void{
          parent.addEventListener(ItemAddedEvent.ITEMADDEDEVENT,addItemToCartEventHandler);
        }

        private function addItemToCartEventHandler(event:ItemAddedEvent){
          text+="Yes! Someone has put " + event.itemDescription + "\n";
        }
        ]]>
    </mx:Script>
</mx:TextArea>

Listing 6. ShoppingCart.mxml

There is a design pattern called Inversion of Control or Dependency Injection, which means that an object does not ask other objects for required values, but rather assumes that someone will provide the required values from outside. This is also known as a Hollywood principle: ”Don’t call me, I’ll call you”.  Our ShoppingCart does exactly this – it waits until some unknown object will trigger event it listens to that will carry item description. Our component knows what to do with it, i.e. display in the red text area, validate against the inventory, send it over to the shipping department, and so on.

Next, we will completely rework our LargeGreenButton class into NewItem component - to include a label and a text field to enter some item description, andthe same old green button:
<?xml version="1.0" encoding="utf-8"?>
<mx:HBox     xmlns:mx="http://www.adobe.com/2006/mxml" >
    
    <mx:Metadata>
        [Event(name="addItemEvent", type="flash.events.Event")]
    </mx:Metadata>
    <mx:Label  text="Item name:"/>
    <mx:TextInput id="enteredItem" width="300"/>
    <mx:Button
        width="104" height="28" cornerRadius="10" fillColors="[#00ff00, #00B000]"
        label="Add Item" fontSize="12" click="greenClickEventHandler()"/>
    <mx:Script>
        <![CDATA[
            import cart.ItemAddedEvent;
            private function greenClickEventHandler():void{
                trace("Ouch! I got clicked! Let me tell this to the world.");
                dispatchEvent(new ItemAddedEvent(enteredItem.text));
            }
        ]]>
    </mx:Script>
</mx:HBox>

When we look at our new application with new ShoppingCart and NewItem components, it is almost indistinguishable from the original one. If we would of kept the old class names, we could of used the old application.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical"
    xmlns:ctrl="controls.*"   xmlns:cart="cart.*">
    <ctrl:NewItem />
    <cart:ShoppingCart width="350" height="150" fontSize="14"/>
</mx:Application>

Listing 7. RedAndGreenApplication2.mxml

When the user enters the item description and clicks the green one, the application creates a new instance of the ItemAddedEvent, passing the entered item to its constructor, and the ShoppingCart properly properly displays selected ”New Item to Add” on the red carpet.
 

Figure 3. The output of the RedAndGreenApplication.mxml

Making components loosely bound simplifies development and distribution but comes at higher cost during testing/maintenance times. Depending on delivery timeline, size and lifespan of your application you would have to make a choice between loosely coupled or strongly typed components. One last note. The itemDescription in Listing 2 does not have access level qualifier. It’s so called package level protection. The ShoppingCart can access itemDescription directly, but the classes outside of “cart” package can’t.

Event-driven programming is nothing new - we routinely did it in mid-nineties in such toos as PowerBuilder or Visual Basic. In Java, it also exists as an  implementation of Observer/Observable pattern. But entire Flex programming is built on events, which makes coding a lot simplier.