Chapter 12

Using Selection Widgets

In Chapter 11, you saw how fields could have constraints placed on them to limit possible input, such as numeric-only or phone-number-only. These sorts of constraints help users “get it right” when entering information, particularly on mobile devices with cramped keyboards.

Of course, the ultimate in constrained input is to allow selection only from a set of items, such as a group of radio buttons. Classic UI toolkits have list boxes, combo boxes, drop-down lists, and the like for that very purpose. Android provides many of the same sorts of widgets, plus others of particular interest for mobile devices (e.g., the Gallery for examining saved photos).

Moreover, Android offers a flexible framework for determining which choices are available in these widgets. Specifically, Android offers a framework of data adapters that provides a common interface for selection lists, ranging from static arrays to database contents. Selection views—widgets for presenting lists of choices—are handed an adapter to supply the actual choices.

Adapting to the Circumstances

In the abstract, adapters provide a common interface to multiple disparate APIs. More specifically, in Android’s case, adapters provide a common interface to the data model behind a selection-style widget, such as a list box. This use of Java interfaces is fairly common (e.g., Java/Swing’s model adapters for JTable), and Java is far from the only environment offering this sort of abstraction (e.g., Flex’s XML data-binding framework accepts XML inlined as static data or retrieved from the Internet).

Android’s adapters are responsible not only for providing the roster of data for a selection widget, but also for converting individual elements of data into specific views to be displayed inside the selection widget. The latter facet of the adapter system may sound a little odd, but in reality, it is not that different from other GUI toolkits’ ways of overriding default display behavior. For example, in Java/Swing, if you want a JList-backed list box to actually be a checklist (where individual rows are a check box plus label, and clicks adjust the state of the check box), you inevitably wind up calling setCellRenderer() to supply your own ListCellRenderer, which in turn converts strings for the list into JCheckBox-plus-JLabel composite widgets.

The easiest adapter to use is ArrayAdapter. You simply wrap one of these around a Java array or java.util.List instance, and you have a fully functioning adapter:

One flavor of the ArrayAdapter constructor takes three parameters:

• The Context to use (typically this will be your activity instance)
• The resource ID of a view to use (such as a built-in system resource ID, as shown in the preceding example)
• The actual array or list of items to show

By default, the ArrayAdapter will invoke toString() on the objects in the list and wrap each of those strings in the view designated by the supplied resource. android.R.layout.simple_list_item_1 simply turns those strings into TextView objects. Those TextView widgets, in turn, will be shown in the list, spinner, or whatever widget uses this ArrayAdapter. If you want to see what android.R.layout.simple_list_item_1 looks like, you can find a copy of it in your SDK installation—just search for simple_list_item_1.xml.

In Chapter 13, you’ll see how to subclass an adapter and override row creation, to give you greater control over how rows appear.

Lists of Naughty and Nice

The classic list box widget in Android is known as ListView. Include one of these in your layout, invoke setAdapter() to supply your data and child views, and attach a listener via setOnItemSelectedListener() to find out when the selection has changed. With that, you have a fully functioning list box.

However, if your activity is dominated by a single list, you might consider creating your activity as a subclass of ListActivity, rather than the regular Activity base class. If your main view is just the list, you do not even need to supply a layout—ListActivity will construct a full-screen list for you. If you do want to customize the layout, you can, as long as you identify your ListView as @android:id/list, so ListActivity knows which widget is the main list for the activity.

For example, here is a layout pulled from the Selection/List sample project, a simple list with a label on top to show the current selection:

The Java code to configure the list and connect the list with the label is as follows:

With ListActivity, you can set the list adapter via setListAdapter()—in this case, providing an ArrayAdapter wrapping an array of nonsense strings. To find out when the list selection changes, override onListItemClick() and take appropriate steps based on the supplied child view and position—in this case, updating the label with the text for that position. The results are shown in Figure 12–1.

Figure 12–1. The ListViewDemo sample application

The second parameter to our ArrayAdapter, android.R.layout.simple_list_item_1, controls the appearance of the rows. The value used in the preceding example provides the standard Android list row: big font, a lot of padding, and white text.

Selection Modes

By default, ListView is set up to simply collect clicks on list entries. If you want a list that tracks a user’s selection, or possibly multiple selections, ListView can handle that as well, but it requires a few changes.

First, you need to call setChoiceMode() on the ListView in Java code to set the choice mode, supplying either CHOICE_MODE_SINGLE or CHOICE_MODE_MULTIPLE as the value. You can get your ListView from a ListActivity via getListView(). You can also declare this via the android:choiceMode attribute in your layout XML.

Then, instead of using android.R.layout.simple_list_item_1 as the layout for the list rows in your ArrayAdapter constructor, you need to use either android.R.layout.simple_list_item_single_choice or android.R.layout.simple_list_item_multiple_choice for single-choice or multiple-choice lists, respectively.

For example, here is an activity layout from the Selection/Checklist sample project:

It is a full-screen ListView, with the android:choiceMode="multipleChoice" attribute to indicate that we want multiple-choice support.

Our activity simply uses a standard ArrayAdapter on our list of nonsense words, but uses android.R.layout.simple_list_item_multiple_choice as the row layout:

The user sees the list of words on the left with check boxes down the right edge, as shown in Figure 12–2.

Figure 12–2. Multiple-select mode

If we wanted to, we could call getCheckedItemPositions() on our ListView to find out which items the user checked, or setItemChecked() to check (or uncheck) a specific entry ourselves.

Spin Control

In Android, the Spinner is the equivalent of the drop-down selector you might find in other toolkits (e.g., JComboBox in Java/Swing). Pressing the center button on the D-pad pops up a selection dialog box from which the user can choose an item. The Spinner basically provides list selection capabilities without taking up all the screen space of a ListView, at the cost of an extra click or screen tap to make a change.

As with ListView, you provide the adapter for data and child views via setAdapter(), and hook in a listener object for selections via setOnItemSelectedListener().

If you want to tailor the view used when displaying the drop-down perspective, you need to configure the adapter, not the Spinner widget. Use the setDropDownViewResource() method to supply the resource ID of the view to use.

For example, culled from the Selection/Spinner sample project, here is an XML layout for a simple view with a Spinner:

This is the same view as shown in the previous section, but with a Spinner instead of a ListView. The Spinner property android:drawSelectorOnTop controls whether the arrow is drawn on the selector button on the right side of the Spinner UI.

To populate and use the Spinner, we need some Java code:

Here, we attach the activity itself as the selection listener (spin.setOnItemSelectedListener(this)). This works because the activity implements the OnItemSelectedListener interface. We configure the adapter not only with the list of fake words, but also with a specific resource to use for the drop-down view (via aa.setDropDownViewResource()). Also note the use of android.R.layout.simple_spinner_item as the built-in View for showing items in the spinner itself.

Finally, we implement the callbacks required by OnItemSelectedListener to adjust the selection label based on user input. Figures 12–3 and 12–4 show the results.

Figure 12–3. The SpinnerDemo sample application, as initially launched

Figure 12–4. The same application, with the spinner drop-down list displayed

Grid Your Lions (or Something Like That...)

As the name suggests, GridView gives you a two-dimensional grid of items to choose from. You have moderate control over the number and size of the columns; the number of rows is dynamically determined based on the number of items the supplied adapter says are available for viewing.

There are a few properties that, when combined, determine the number of columns and their sizes:

• android:numColumns: Indicates how many columns there are, or, if you supply a value of auto_fit, Android will compute the number of columns based on the available space and the following properties in this list.
• android:verticalSpacing and android:horizontalSpacing: Indicate how much whitespace should exist between items in the grid.
• android:columnWidth: Indicates how many pixels wide each column should be.
• android:stretchMode: Indicates, for grids with auto_fit for android:numColumns, what should happen for any available space not taken up by columns or spacing. This can be columnWidth, to have the columns take up available space, or spacingWidth, to have the whitespace between columns absorb extra space.

Otherwise, the GridView works much like any other selection widget—use setAdapter() to provide the data and child views, invoke setOnItemSelectedListener() to register a selection listener, and so on.

For example, here is an XML layout from the Selection/Grid sample project, showing a GridView configuration:

For this grid, we take up the entire screen except for what our selection label requires. The number of columns is computed by Android (android:numColumns = "auto_fit") based on our horizontal spacing (android:horizontalSpacing = "5dip") and column width (android:columnWidth = "100dip"), with the columns absorbing any “slop” width left over (android:stretchMode = "columnWidth").

The Java code to configure the GridView is as follows:

The grid cells are defined by a separate res/layout/cell.xml file, referenced in our ArrayAdapter as R.layout.cell:

With the vertical spacing from the XML layout (android:verticalSpacing = "40dip"), the grid overflows the boundaries of the emulator’s screen, as shown in Figures 12–5 and 12–6.

Figure 12–5. The GridDemo sample application, as initially launched

Figure 12–6. The same application, scrolled to the bottom of the grid

Fields: Now with 35% Less Typing!

The AutoCompleteTextView is sort of a hybrid between the EditText (field) and the Spinner. With autocompletion, as the user types, the text is treated as a prefix filter, comparing the entered text as a prefix against a list of candidates. Matches are shown in a selection list that drops down from the field (as with Spinner). The user can either type the full entry (e.g., something not in the list) or choose an item from the list to be the value of the field.

AutoCompleteTextView subclasses EditText, so you can configure all the standard look-and-feel aspects, such as font face and color. In addition, AutoCompleteTextView has an android:completionThreshold property, to indicate the minimum number of characters a user must enter before the list filtering begins.

You can give AutoCompleteTextView an adapter containing the list of candidate values via setAdapter(). However, since the user could type something that is not in the list, AutoCompleteTextView does not support selection listeners. Instead, you can register a TextWatcher, as you can with any EditText widget, to be notified when the text changes. These events will occur either because of manual typing or from a selection from the drop-down list.

The following is a familiar XML layout, this time containing an AutoCompleteTextView (pulled from the Selection/AutoComplete sample application):

The corresponding Java code is as follows:

This time, our activity implements TextWatcher, which means our callbacks are onTextChanged(), beforeTextChanged(), and afterTextChanged(). In this case, we are interested only in onTextChanged(), and we update the selection label to match the AutoCompleteTextView’s current contents. Figures 12–7, 12–8, and 12–9 show the results.

Figure 12–7. The AutoCompleteDemo sample application, as initially launched

Figure 12–8. The same application, after a few matching letters were entered, showing the autocomplete drop-down

Figure 12–9. The same application, after the autocomplete value was selected

Galleries, Give or Take the Art

The Gallery widget is not one ordinarily found in GUI toolkits. It is, in effect, a list box that is laid out horizontally. One choice follows the next across the horizontal plane, with the currently selected item highlighted. On an Android device, the user rotates through the options via the left and right D-pad buttons.

Compared to the ListView, the Gallery takes up less screen space, while still showing multiple choices at one time (assuming they are short enough). Compared to the Spinner, the Gallery always shows more than one choice at a time.

The quintessential example use for the Gallery is image preview. Given a collection of photos or icons, the Gallery lets people preview the pictures in the process of choosing one.

Code-wise, the Gallery works much like a Spinner or GridView. In your XML layout, you have a few properties at your disposal:

• android:spacing: Controls the number of pixels between entries in the list.
• android:spinnerSelector: Controls what is used to indicate a selection. This can either be a reference to a Drawable (see the resources chapter) or an RGB value in #AARRGGBB or similar notation.

android:drawSelectorOnTop: Indicates if the selection bar (or Drawable) should be drawn before (false) or after (true) drawing the selected child. If you choose true, be sure that your selector has sufficient transparency to show the child through the selector; otherwise, users will not be able to read the selection.