CHAPTER 8. Using Selection Widgets

In Chapter 6, you saw how fields could have constraints placed upon 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 a mobile device with cramped keyboards.

Of course, the ultimate in constrained input is to select a choice from a set of items, such as the radio buttons seen earlier. Classic UI toolkits have listboxes, comboboxes, drop-down lists, and the like for that very purpose. Android has 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 what choices are available in these widgets. Specifically, Android offers a framework of data adapters that provide a common interface to 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 listbox. 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 for providing the roster of data for a selection widget plus 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 listbox to actually be a checklist (where individual rows are a checkbox plus label, and clicks adjust the state of the checkbox), 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.

Using ArrayAdapter

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

String[] items={this, is, a,

 really, silly, list};

new ArrayAdapter(this,

 android.R.layout.simple_list_item_1, items);

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 previously shown)

• 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 the list or spinner or whatever widget uses this ArrayAdapter.

You can subclass ArrayAdapter and override getView() to “roll your own” views:

public View getView(int position, View convertView,

 ViewGroup parent) {

 if (convertView==null) {

  convertView = new TextView(this);

 }

 convertView.setText(buildStringFor(position));

 return(convertView);

}

Here, getView() receives three parameters:

• The index of the item in the array to show in the view

• An existing view to update with the data for this position (if one already existed, such as from scrolling — if null, you need to instantiate your own)

• The widget that will contain this view, if needed for instantiating the view

In the previous example, the adapter still returns a TextView, but uses a different behavior for determining the string that goes in the view. Chapter 9 will cover fancier ListViews.

Other Key Adapters

Here are some other adapters in Android that you will likely use:

• CursorAdapter converts a Cursor, typically from a content provider, into something that can be displayed in a selection view

• SimpleAdapter converts data found in XML resources

• ActivityAdapter and ActivityIconAdapter provide you with the names or icons of activities that can be invoked upon a particular intent

Lists of Naughty and Nice

The classic listbox 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 listbox.

However, if your activity is dominated by a single list, you might well 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, so 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. This sample along with all others in this chapter can be found in the Source Code area of http://apress.com.

 xmlns:android="http://schemas.android.com/apk/res/android"

 android:orientation="vertical"

 android:layout_width="fill_parent"

 android:layout_height="fill_parent">

 

  android:id="@+id/selection"

  android:layout_width="fill_parent"

  android:layout_height="wrap_content"/>

 

  android:id="@android:id/list"

  android:layout_width="fill_parent"

  android:layout_height="fill_parent"

  android:drawSelectorOnTop="false"

 />

It is just a 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:

public class ListViewDemo extends ListActivity {

 TextView selection;

 String[] items={"lorem", "ipsum", "dolor", "sit", "amet",

  "consectetuer", "adipiscing", "elit", "morbi", "vel",

  "ligula", "vitae", "arcu", "aliquet", "mollis",

  "etiam", "vel", "erat", "placerat", "ante",

  "porttitor", "sodales", "pellentesque", "augue", "purus"};

 @Override

 public void onCreate(Bundle icicle) {

  super.onCreate(icicle);

  setContentView(R.layout.main);

  setListAdapter(new ArrayAdapter(this,

   android.R.layout.simple_list_item_1,

   items));

  selection=(TextView)findViewById(R.id.selection);

 }

 public void onListItemClick(ListView parent, View v, int position,

  long id) {

  selection.setText(items[position]);

 }

}

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 8-1.

1

Figure 8-1. The ListViewDemo sample application

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 for the user to choose an item from. You basically get the ability to select from a list 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:

 xmlns:android="http://schemas.android.com/apk/res/android"

 android:orientation="vertical"

 android:layout_width="fill_parent"

 android:layout_height="fill_parent">

 

  android:id="@+id/selection"

  android:layout_width="fill_parent"

  android:layout_height="wrap_content"

 />

 

  android:layout_width="fill_parent"

  android:layout_height="wrap_content"

  android:drawSelectorOnTop="true"

 />

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

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

public class SpinnerDemo extends Activity

 implements AdapterView.OnItemSelectedListener {

 TextView selection;

 String[] items={"lorem", "ipsum", "dolor", "sit", "amet",

  "consectetuer", "adipiscing", "elit", "morbi", "vel",

  "ligula", "vitae", "arcu", "aliquet", "mollis",

  "etiam", "vel", "erat", "placerat", "ante",

  "porttitor", "sodales", "pellentesque", "augue", "purus"};

 @Override

 public void onCreate(Bundle icicle) {

  super.onCreate(icicle);

  setContentView(R.layout.main);

  selection = (TextView)findViewById(R.id.selection);

  Spinner spin = (Spinner)findViewById(R.id.spinner);

  spin.setOnItemSelectedListener(this);

  ArrayAdapter aa = new ArrayAdapter(this,

  android.R.layout.simple_spinner_item, items);

  aa.setDropDownViewResource(

   android.R.layout.simple_spinner_dropdown_item);

  spin.setAdapter(aa);

 }

 public void onItemSelected(AdapterView parent,

  View v, int position, long id) {

  selection.setText(items[position]);

 }

 public void onNothingSelected(AdapterView parent) {

  selection.setText("");

 }

}

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.

The resulting application is shown in Figures 8-2 and 8-3.

1

Figure 8-2. The SpinnerDemo sample application, as initially launched

1

Figure 8-3. 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 which, when combined, determine the number of columns and their sizes:

• android:numColumns spells out how many columns there are, or, if you supply a value of auto_fit, Android will compute the number of columns based on available space and the following properties.

• android:verticalSpacing and its counterpart android:horizontalSpacing indicate how much whitespace there should be 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 should be columnWidth to have the columns take up available space or spacingWidth to have the whitespace between columns absorb extra space. For example, suppose the screen is 320 pixels wide, and we have android:columnWidth set to 100px and android:horizontalSpacing set to 5px. Three columns would use 310 pixels (three columns of 100 pixels and two whitespaces of 5 pixels). With android:stretchMode set to columnWidth, the three columns will each expand by 3–4 pixels to use up the remaining 10 pixels. With android:stretchMode set to spacingWidth, the two whitespaces will each grow by 5 pixels to consume the remaining 10 pixels.

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, etc.

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

 xmlns:android="http://schemas.android.com/apk/res/android"

 android:orientation="vertical"

 android:layout_width="fill_parent"

 android:layout_height="fill_parent">

 

  android:id="@+id/selection"

  android:layout_width="fill_parent"

  android:layout_height="wrap_content"

 />

 

  android:id="@+id/grid"

  android:layout_width="fill_parent"

  android:layout_height="fill_parent"

  android:verticalSpacing="35px"

  android:horizontalSpacing="5px"

  android:numColumns="auto_fit"

  android:columnWidth="100px"

  android:stretchMode="columnWidth"

  android:gravity="center"

 />

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 5-pixel horizontal spacing (android:horizontalSpacing="5px"), 100-pixel columns (android:columnWidth="100px"), with the columns absorbing any “slop” width left over (android:stretchMode="columnWidth").

The Java code to configure the GridView is:

public class GridDemo extends Activity

 implements AdapterView.OnItemSelectedListener {

 TextView selection;

 String[] items={"lorem", "ipsum", "dolor", "sit", "amet",

  "consectetuer", "adipiscing", "elit", "morbi", "vel",

  "ligula", "vitae", "arcu", "aliquet", "mollis",

  "etiam", "vel", "erat", "placerat", "ante",

  "porttitor", "sodales", "pellentesque", "augue", "purus"};

 @Override

 public void onCreate(Bundle icicle) {

  super.onCreate(icicle);

  setContentView(R.layout.main);

  selection = (TextView)findViewById(R.id.selection);

  GridView g=(GridView)findViewById(R.id.grid);

  g.setAdapter(new FunnyLookingAdapter(this,

   android.R.layout.simple_list_item_1, items));

  g.setOnItemSelectedListener(this);

 }

 public void onItemSelected(AdapterView parent, View v,

  int position, long id) {

  selection.setText(items[position]);

 }

 public void onNothingSelected(AdapterView parent) {

  selection.setText("");

 }

 private class FunnyLookingAdapter extends ArrayAdapter {

  Context ctxt;

  FunnyLookingAdapter(Context ctxt, int resource,

   String[] items) {

   super(ctxt, resource, items);

   this.ctxt = ctxt;

  }

  public View getView(int position, View convertView,

   ViewGroup parent) {

   TextView label = (TextView)convertView;

   if (convertView==null) {

    convertView = new TextView(ctxt);

    label = (TextView)convertView;

   }

   label.setText(items[position]);

   return(convertView);

  }

 }

}

For the grid cells, rather than using auto-generated TextView widgets as in the previous sections, we create our own views, by subclassing ArrayAdapter and overriding getView(). In this case, we wrap the funny-looking strings in our own TextView widgets, just to be different. If getView() receives a TextView, we just reset its text; otherwise, we create a new TextView instance and populate it.

With the 35-pixel vertical spacing from the XML layout (android:verticalSpacing="35"), the grid overflows the boundaries of the emulator’s screen as shown in Figures 8-4 and 8-5.

1

Figure 8-4. The GridDemo sample application, as initially launched

1

Figure 8-5. 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 auto-completion, 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, like with Spinner, folds down from the field. The user can either type out an entry (e.g., something not in the list) or choose an entry 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 a 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 not in the list, AutoCompleteTextView does not support selection listeners. Instead, you can register a TextWatcher, like you can with any EditText, 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-looking XML layout, this time containing an AutoCompleteTextView (pulled from the Selection/AutoComplete sample application):

 xmlns:android="http://schemas.android.com/apk/res/android"

 android:orientation="vertical"

 android:layout_width="fill_parent"

 android:layout_height="fill_parent">

 

  android:id="@+id/selection"

  android:layout_width="fill_parent"

  android:layout_height="wrap_content"

 />

 

  android:layout_width="fill_parent"

  android:layout_height="wrap_content"

  android:completionThreshold="3"/>

The corresponding Java code is:

public class AutoCompleteDemo extends Activity

 implements TextWatcher {

 TextView selection;

 AutoCompleteTextView edit;

 String[] items={"lorem", "ipsum", "dolor", "sit", "amet",

  "consectetuer", "adipiscing", "elit", "morbi", "vel",

  "ligula", "vitae", "arcu", "aliquet", "mollis",

  "etiam", "vel", "erat", "placerat", "ante",

  "porttitor", "sodales", "pellentesque", "augue", "purus"};

 @Override

 public void onCreate(Bundle icicle) {

  super.onCreate(icicle);

  setContentView(R.layout.main);

  selection = (TextView)findViewById(R.id.selection);

  edit = (AutoCompleteTextView)findViewById(R.id.edit);

  edit.addTextChangedListener(this);

  edit.setAdapter(new ArrayAdapter(this,

   android.R.layout.simple_dropdown_item_1line, items));

 }

 public void onTextChanged(CharSequence s, int start, int before,

  int count) {

  selection.setText(edit.getText());

 }

 public void beforeTextChanged(CharSequence s, int start,

  int count, int after) {

  // needed for interface, but not used

 }

 public void afterTextChanged(Editable s) {

  // needed for interface, but not used

 }

}

This time, our activity implements TextWatcher, which means our callbacks are onTextChanged() and beforeTextChanged(). In this case, we are only interested in the former, and we update the selection label to match the AutoCompleteTextView’s current contents.

Figures 8-6, 8-7, and 8-8 show the application results.

1

Figure 8-6. The AutoCompleteDemo sample application, as initially launched

1

Figure 8-7. The same application, after a few matching letters were entered, showing the auto-complete drop-down

1

Figure 8-8. The same application, after the auto-complete 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 horizontally-laid-out listbox. One choice follows the next across the horizontal plane, with the currently-selected item highlighted. On an Android device, one rotates through the options through 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.

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 listbox. 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 for providing the roster of data for a selection widget plus 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 listbox to actually be a checklist (where individual rows are a checkbox plus label, and clicks adjust the state of the checkbox), 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.

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 listbox. 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 for providing the roster of data for a selection widget plus 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 listbox to actually be a checklist (where individual rows are a checkbox plus label, and clicks adjust the state of the checkbox), 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.

Contents