83Working with views

hints about where specifically you want the focus to go using the following View class methods (or their counterparts in XML):

■ nextFocusDown

■ nextFocusLeft

■ nextFocusRight

■ nextFocusUp

Views can also indicate a particular focus type, DEFAULT_FOCUS or WEAK_FOCUS, to set the priority of focus they desire, themselves (default) versus their descendants (weak). In addition to hints, such as UP, DOWN, and WEAK, you can use the View.requestFocus()

method directly, if need be, to indicate that focus should be set to a particular View at a given time. Manipulating the focus manually should be the exception rather than the rule (the platform logic generally does what you would expect).

Focus gets changed based on event-handling logic using the OnFocusChange- Listener object and related setOnFocusChangedListener() method. This takes us into the world of event handling in general.

3.2.7 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 pro- cess 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.

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

observerCollection : Collection<Observer> (Listeners) Observable (Source) notify() : void Observer (Listener) ObserverImpl ObserveableImpl For observer in observerCollection: notifyObserver() * 0..1

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 incom- ing phone call occurs or a GPS-based location changes based on physical move- ment, 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 win- dow), 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.

3.3

Using resources

We have mentioned Android resources in several areas up to now, and they were ini- tially introduced in chapter 1. Here we will revisit resources with more depth in order to expand on this important topic and to begin completing the third and final Activ- ity in RestaurantFinder—the ReviewDetail screen.

When you begin working with Android you will quickly notice many references to a class named R. This class was introduced in chapter 1, and we have used it in our pre- vious Activity examples in this chapter. This is the Android resources reference

85