Handling User Interaction BLACKBERRY

Now, we have a screen that looks the way we want it to but it doesn’t do anything yet— well, you can move the focus between controls, type in the text fields, and change the check box and the choice field, but the application doesn’t really do anything yet. Let’s get those buttons to work!

Handling UI Events

The BlackBerry API uses an observer pattern to dispatch events: All fields can have a listener attached to them, and that listener is notified when a change event happens. The exact trigger for a change event varies from field to field.

In the case of ButtonField, the change event happens when the button is clicked by the trackball or a touch on the touch screen, or when the Enter key is pressed while a button is highlighted. For CheckboxField, a change event happens when the check box is checked or unchecked, and for ChoiceField, an event happens whenever the user selects a different choice.You attach a listener using the Field.setChangeListener method.

Note that the BlackBerry provides a unicast event model: there is only ever at most one change listener for a field. If you use Field.setChangeListener, you replace whatever listener may have been there already, preventing it from receiving events. This makes a lot of sense for a mobile platform where resources and application scope are limited but may be different from what you’re used to with desktop or server application development.

A listener must implement the FieldChangeListener interface. In this case, we’ll make our UiFunMainScreen implement net.rim.device.api.ui.FieldChangeListener by changing the class declaration and implementing the listener method in UiFunMainScreen:

Remember to add an import for net.rim.device.api.ui.FieldChangeListener to the top of the Java file. The field parameter is a reference to the field that originated the change, in this case, one of our ButtonField instances (once we’ve added them). The context can mean different things: when you define your own fields, you can use it to pass along additional information about the field change event. For this application, we’ll ignore the context parameter.

Handling the Clear Button

We’ll hook up the Clear button first. Add the following line in the constructor, just after instantiating the button:


Now, when the user clicks on the clear button, we’ll receive an event in
UiFunMainScreen.fieldChanged. We can test this with a simple dialog using the
net.rim.device.api.ui.component.Dialog class:

The Dialog class is a handy way of displaying simple messages to the user. Run the application, and click Clear to see that we’re correctly handling and receiving the event.

An event from the Clear button

An event from the Clear button

Of course, what we actually want the Clear button to do is remove all text from our fields. Let’s define a method to do this. Add the following to UiFunMainScreen:

Now, clicking Clear will erase the text from both of our fields (see Figure).

When the fields are populated (as in the image on the left), clicking the Clear button removes the text from the fields (as shown in the image on the right).

Clear button removes the text from the fields (as shown in the image on the right).

Handling the Login Button

We’ll do two things with our Login button: Check that both fields have some text in them and display a warning dialog if they don’t. And, if both have been filled in, display a new screen informing the user that login was successful.

Defining a New Screen

To keep the flow of everything fairly logical, let’s define the login success screen now. It will be a simple screen with three label fields, one each to show a successful login, the username, and the selected domain. We’ll pass the username and domain in the constructor of the screen. The entire code for LoginSuccessScreen is as follows:

We display the new screen in the same way as we displayed UiFunMainScreen from UiFunApplication, but here, we have to get a reference to our UiApplication instance first.
UiApplication.getUiApplication() will give us that; in fact, it’s a reference to the very same instance of UiFunApplication that we created in our main method. The code will look something like this:

As we did with the Clear button, we’ll define a method to perform the login logic described previously. We need the name of the selected domain to pass to the new screen; we can get the index of the currently selected item in domainField by calling domainField. get Selected Index(), and we can get the choice associated with that index by calling domainField. get Choice(int). The getChoice method returns an Object. However, because all the objects we passed into the constructor for domainField were Strings, we can safely cast the result of getChoice back to a String. The full code for UiFunMainScreen.login follows:

We’ll have to modify fieldChanged to handle the login button as well:

Finally, remember to add the change listener to loginButton in UiFunMainScreen’s constructor:


When you run the application now, you’ll see the result show in Figure.

Clicking Login without a username a password (left) and with a username and password (right)

Clicking Login without a username a password (left) and with a username and password (right)

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status