Grasping events

Events are used for changing the focus and for many other actions as well. We have already implemented several onClickListener() methods for buttons in listing 3.2. Those OnClickListener instances were connected to button presses. The events they were indicating were "Hey, somebody pressed me." This is exactly the same process that focus events go through when announcing or responding to OnFocus-Change events.

Events have two halves: the component raising the event and the component (or components) that responds to the event. These two halves are variously known as Observable and Observer in design pattern terms (or sometimes subject and observer). Figure 3.7 is a class diagram of the relationships in this pattern.

An Observable component provides a way for Observer instances to register. When an event occurs, the Observable notifies all the observers that something has taken place. The observers can then respond to that notification however they see fit. Interfaces are typically used for the various types of events in a particular API.

Observable (Source)

observerCollection : Collection<Observer> (Listeners)

registerObserver() : void unregisterObserver(): void notifyObserver(): void

ObserveableImpl i

For observer in observerCollection notifyObserver()

Observer (Listener)

notify()

void

ObserverImpl

Figure 3.7 A class diagram depicting the Observer design pattern. Each Observable component has zero to many Observers, which can be notified of changes when necessary.

With regard to an Android Button the two halves are represented as follows:

■ Observable—Button.setOnClickListener(OnClickListener listener)

■ Observer—listener.onClick(View v)

This pattern comes into play in terms of Android View items in that many things are Observable and allow other components to attach and listen for events. For example, most of the View class methods that begin with on are related to events: onFocusChanged(), onSizeChanged(), onLayout(), onTouchEvent(), and the like. Similarly, the Activity lifecycle methods we have already discussed—onCreate(), onFreeze(), and such—are also event-related (on a different level).

Events happen in the UI and all over the platform. For example, when an incoming phone call occurs or a GPS-based location changes based on physical movement, many different reactions may occur down the line; many components may want to be notified when the phone rings or when the location changes (not just one and not just the UI). Views support events on many levels. When an interface event comes in (a user pressed a button, or scrolled, or selected a portion of a window), it is dispatched to the appropriate view. In general, click events, keyboard events, touch events, and focus events are the main types of events you will deal with in the UI.

One very important aspect of the View in Android is that the interface is single-threaded. If you are calling a method on a View, you have to be on the UI thread. This is, again, why we used a Handler in listing 3.3—to get data outside of the UI thread and notify the UI thread to update the View via the setMessage() event.

We are admittedly discussing events here on a fairly broad level, to make sure that the overarching concepts are clear. We do this because we cannot cover all of the event methods in the Android APIs in one chapter. Yet you will see events in examples throughout the book and in your day-to-day experiences with the platform. We will call out event examples when necessary, and we will cover them in more detail as we come to specific examples.

Our coverage of events in general, and how they relate to layout, rounds out the majority of our discussion of views, but we still have one notable related concept to tackle, resources. Views are closely related to resources, but they also go beyond the UI. In the next section we will address all the aspects of resources, including XML-defined views.

0 0

Post a comment