©2011 Elsevier, Inc. All rights reserved. This excerpt is published by permission of the copyright holder/publisher:
Data Visualization in Flash Builder: Designing RIA and AIR Applications with Remote Data Sources, by Cesare Rocchi
ISBN: 978-0-240-81503-9
Events
As we have seen in the previous section, a components in Flex has many features like size, style, behavior. A key feature of Flex components is the ability to dispatch and/or listen to events. An event is something that happens. Whether initiated by the user (e.g. a click) or by the system (an image is loaded) an event is a data structure used to notify that something has happened. Below is a list of events:
- the user resized a window;
- the login information is wrong;
- the Flex application has started
- the UI of the Flex application has been rendered
- the user changed the value of a text input
- the url specified does not exist
- the application is going to be closed
Events are not specific of Flex. In fact, they were already included in Actionscript version 1. Although changed and refined since then, events still remain a key components of the Flash platform and client web programming in general.
When we program for the web we have to keep in mind that it is an asynchronous “world”. This means there is to wait. For example, when you need to log in to a service, the following happens under the hood (roughly):
- read data provided (login and password)
- ask the backend to validate data
- show the result (correct or wrong)
The second operation, ask the backend, is the asynchronous one. In this case you ask something and you wait for the response. This does not mean that your application is blocked. Indeed, all the parts that do not depend on the result of the asynchronous operation, can be executed (e.g. banner at the bottom, news from the blog, etc.). This is an advantage in that it shows the user that not everything is “stuck”. The downside of this approach is that the programmer has to deal with asynchronous programming and notifications. For example, each asynchronous operation can have at least a positive and a negative result. As a developer/designer it is a good practice to specify both and to notify the user accordingly. Moreover, in the http world, things can go wrong for many reasons so it is not unusual to notify specific errors or situations. For example, the application can not login because of the following errors:
- username does not exist
- wrong combination of username and password
- no internet connection
- login service unavailable
Although all these situations are similar to the final user (“Can't login”) there are differences that we might want to signal at UI level. That means for each of these events we can provide a UI behavior (e.g. pop up a message). Events in Flash are important not just because we know when something happens, but because we can associate one or more actions to an event. In fact when you talk about event there are two key actions associated: listening and reacting. Let's try to start with an example.
The login scenario
In the previous section we have seen how to build the UI of login form. Let's resume from there. When the user clicks the button the application sends data to the backend and waits for a response. At this point the developer has to have already specified all the behaviors of the UI in the different cases. To start let's just consider two generic cases, success and failure.
First of all, it is a good practice to notify the user that something is happening. When he clicks the login button we should show a spinner or some “ongoing-activity” signal, we should remember to remove it whether the procedure is a success or a failure. Wait a second ... aren't these states? Yes!
Then we could arrange our logic in term of states. How? We listen to the login service on the backend and we display the UI panel accordingly.
States and Events for Login Scenario
We can dispose our application according to the following table.
The first event is triggered by the user, the second and third are generated by the backend. Out UI can react to all of these events and switch to the correspondent state. First let's setup the UI. We report below part of the code developed in the first section.
The graphical counterpart is shown in the following figure.
We will follow the same method adopted in section 1, we first create the needed elements and then we arrange them according to the state. To the current implementation we need to add a label and a rectangle. The table below shows how these elements are used.
In the initial state the new label and the rectangle are hidden. In the first we have to show just the label and set its text. The second and the third are similar and display both the rectangle and the label. We have already seen how to work with states in Flash Builder (section 1), so we simply report the code you should end up with.
If you preview you will notice that the label is empty and the rectangle is black (default color). Now we have to declare where to include these elements and how their properties (color and text) vary according to states. Let's start with the label.
Instead of including it in three states, we exclude it from the “Initial”. Setting text is pretty intuitive. Now we can move on to the rectangle.
The UI is now ready to react according to different events. Let's see how we can listen to events and associate an action each time we catch one.
Login web service
Here we illustrate a simple web service which simulates login. Please do not consider it as good backend programming. It is just a way to show how the UI works in case of success and failure. We will do it in php, just because we think it is easier to set up locally.
In our example we have set up MAMP1, a bundle which allows installing the Apache web server, with PHP and MySQL configured, on a local machine2. Let's have a look at the code.
ok";
} else {
echo "wrong";
}
} else {
echo "nodata";
}
?>
The output of this service is always in xml format. It is an “ok” string if username and password are matched, “wrong” otherwise. A third case is detected when no values are passed (“nodata”). Parameters are passed as POST variables, named 'username' and 'password'3. These are two arbitrary names, which can be changed as you wish. It is important that they are the same both on the client (Flash) and the server (php in this case). If there is no match the application might not work as expected, so it is strongly suggested that developers agree on the names of variables on the front/back-end.
Hooking UI to Web Service
Now we will see how to connect the UI to the web service we have just set up. We already know how to do it by using the “Data/Services” wizard of Flash builder (see section 1). Since we should now feel more comfortable with the code tab we will build this example by typing code. We need one Flex element we never met so far, so let's introduce it: HttpService. This is a class which allows loading a specific URL via the http protocol. The minimal elements to provide in order to make it work are a url and a method call to its method, send().
These two pieces of code would be enough to load a url. Usually when you load a url you want to manipulate loaded data or notify whether something went wrong. What enables this in Flash? Events! If you check out the completion of HttpService there are lots of properties. Some of them have a nice orange icon , which represent a thunder. Those are events4. In our scenario we are interested in two events, fault and result. Names are pretty intuitive but they need some explanation anyway.
The result event is fired when the url is correctly loaded. This does not mean that the login is successful every time we receive that event. For example, if we submit the wrong combination of username and password the url is correctly retrieved but the login is not successful. Same when we do not provide data in the post variables. So we need a way to detect not just the type of event but also its content. More on this below. When the fault event is fired? When the web service is not available, or when your client is not connected to the internet: in general when there is a communication problem between the service and the client. In this case we could notify it on the UI.
Now we know which are the hooks to use information provided by the HttpService class. What are the fillers of event properties? Methods.
Technically also a function can be a filler for an event property, though it is a widely adopted (and correct) practice to use methods. Let's see some code.
On lines 3-4 we specify two methods, onResult and onFault, which will be called when the services loads correctly or not. We should remember to specify a formal parameter, event in this case, which will hold the content of the event (e.g. “ok” or “wrong” strings defined in the web service. The url is the same as above, while we should remember to specify that it is a POST request, for the default values is GET.
As we said parameters are to be passed to the server for verification. HttpService has been defined to specify parameters as children, as it follows.
{userInput.text}
{passwordInput.text}
Here we can see another useful usage of binding, which allows to dynamically read the values of the form and send them directly to the web service. We are now left with the definition of methods. This, when executed as a response to an event are commonly referred to as callbacks.
We should be already familiar with this syntax. The only important aspect to highlight is that events are typed (ResultEvent and FaultEvent) and those classes need to be imported.
Now it is time to associate some event to the UI states defined above. If we receive a fault event we can set the UI to the ErrorInLogging state, as follows.
private function onFault(event:FaultEvent):void {
this.currentState = 'ErrorInLogging';
}
The result case is a bit more complex, because we need to identify the reason of the callback. We will define the method as follows.
private function onResult(event:ResultEvent):void {
var res:Boolean = String(event.result.login) == "ok";
if (res)
this.currentState = 'LoggedIn';
else
this.currentState = 'ErrorInLogging';
}
To identify the reason of the callback we have to check the content of the result property of the event, which stores the values as we have defined them on the server. The only positive case is when such a value is equal to “ok”, which is associated to the 'LoggedIn' state (green square). All the rest equals to a negative feedback.
The last step is to trigger the trigger the send procedure when the button is pressed. To be more clear we will define another function and associate it to the click of the button.
private function authenticate():void {
this.currentState = 'Logging';
loginService.send();
}
...
Now we are ready to test our application. If you test it locally probably you don't notice the switch from the initial state to the authenticating phase, but as soon as the service will be online, you and your user will appreciate that feedback. Below are two screenshots when the login is successful or not.
]]>
