jump to navigation

Dispatching Custom Events July 17, 2010

Posted by Tournas Dimitrios in Flex.
trackback

The basic premise behind building loosely coupled components in your applications is that your components share data without being hard wired to each other.This article introduces the concept of creating , dispatching and consuming custom events

By analogy: a car has a gas gauge – the application. The GasGauge has a needle, to display the FuelLevel – a component. There might also be a warning light that lights up to indicate that the FuelLevel is nearing empty.

In the hard wried approach the FuelLevel component would tell the WarningLight component to light up.

In the loosely coupled version the FuelLevel component would dispatch an event – nearingEmptyEvent – to whom ever might happen to be listening. In this case the GasGauge application would be listening. The WarningLight would get it’s cue regarding whether or not be be lite-up by looking at the appropriate property in the application. If either one of these components are removed from the application then nothing breaks.

In this example I have used the DateChooser to create a calendar. When the user clicks on a date another component displays the selected date as a string. Presumably the DisplayDate component would do something a little more complex than simply showing you the date as a string. Perhaps it would update a database or something. I tried to keep this example as simple as possible just to show the essentials.

Here is a simple walk through of the application. The code is thoroughly commented so you might want to skip right to it.

When the user clicks on the DateChooser the Calendar component broadcasts that event – dateChangedEvent. That’s it. It doesn’t do anything else and it doesn’t know, or matter, if anything is listening. It’s responsibility is to simply make the announcement when the event, dateChangedEvent, occurs.

As it happens the main application file – Date_main – is listening. When it receives notice that the dateChangedEvent has occurred it changes its own property – dateAsString.

The dateAsString property is in turn bound to a property of the DisplayDateAsString component – passedDateString. The nice thing about this last part is that it doesn’t take any Actionscript to work. It’s all built in via the binding of component properties.Download and run the source code of this example in FB3 .You will get the following result .

Well if You have fully understand the basic concepts “Dispatching Custum Events “ lets get a little bit more advanced .

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″?>
 xmlns:mx=”<a href="http://www.adobe.com/2006/mxml">http://www.adobe.com/2006/mxml</a>“>
 

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.

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>
<!--[<span class="hiddenSpellError" pre="">CDATA</span>[-->
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>

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:

xmlns:mx=”http://www.adobe.com/2006/mxml”
xmlns:ctrl=”controls.*” layout=”absolute”>
<ctrl:LargeGreenButton addItemEvent=”greenButtonHandler(event)”/>
<mx:Script>
<!--[<span class="hiddenSpellError" pre="">CDATA</span>[-->
private function greenButtonHandler(event:Event):void{
trace("Someone clicked on the Large Green Button!");
}
]]>
</mx:Script>

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.xmxlOur next component will be called BlindShoppingCart. This time we’ll create a component in the “cart” directory based on the TextArea.

TextArea xmlns:mx=”http://www.adobe.com/2006/mxml”
backgroundColor=”#ff0000″ creationComplete=”init()”>
<mx:Script>
<!--[<span class="hiddenSpellError" pre="">CDATA</span>[-->
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>
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.

xmlns:mx=”http://www.adobe.com/2006/mxml” layout=”vertical”
xmlns:ctrl=”controls.*” xmlns:cart=”cart.*”>
<ctrl:LargeGreenButton addItemEvent=”greenButtonHandler(event)”/>
BlindShoppingCart width=”350″ height=”150″ fontSize=”14″/>
<mx:Script>
<!--[<span class="hiddenSpellError" pre="">CDATA</span>[-->
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″?>
xmlns:mx=”http://www.adobe.com/2006/mxml”
backgroundColor=”#ff0000″ creationComplete=”init()”>
<mx:Script>
<!--[<span class="hiddenSpellError" pre="">CDATA</span>[-->
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″?>
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:”/>
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>
<!--[<span class="hiddenSpellError" pre="">CDATA</span>[-->
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″?>
xmlns:mx=”http://www.adobe.com/2006/mxml” layout=”vertical”
xmlns:ctrl=”controls.*” xmlns:cart=”cart.*”>
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.

Furder readings :

Advertisements

Comments»

No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s