The humble ListView
is one of the most important widgets in all of Android, simply because it is used so frequently. Whether choosing a contact to call, an e-mail message to forward, or an e-book to read, ListView
widgets are employed in a wide range of activities. Of course, it would be nice if they were more than just plain text.
The good news is that Android lists can be as fancy as you want, within the limitations of a mobile device’s screen, of course. However, making them fancy takes some work, requiring the features of Android that are covered in this chapter.
The classic Android ListView
is a plain list of text—solid but uninspiring. Basically, we hand the ListView
a bunch of words in an array and tell Android to use a simple built-in layout for pouring those words into a list.
However, we can have a list whose rows are made up of icons, icons and text, check boxes and text, or whatever we want. It is merely a matter of supplying enough data to the adapter and helping the adapter to create a richer set of View
objects for each row.
For example, suppose we want a ListView
whose entries are made up of an icon, followed by some text. We could construct a layout for the row that looks like this, found in res/layout/row.xml
in the FancyLists/Static
sample project:
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical"
android:layout_width="fill_parent"
android:layout_height="fill_parent" >
<TextView
android:id="@+id/selection"
android:layout_width="fill_parent"
android:layout_height="wrap_content"/>
<ListView
android:id="@android:id/list"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:drawSelectorOnTop="false"
/>
</LinearLayout>
This layout uses a LinearLayout
to set up a row, with the icon on the left and the text (in a nice big font) on the right.
However, by default, Android has no idea that we want to use this layout with our ListView
. To make the connection, we need to supply our Adapter
with the resource ID of the custom layout shown previously:
public class StaticDemo extends ListActivity {
private TextView selection;
private static final 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<String>(this,
R.layout.row, R.id.label,
items));
selection=(TextView)findViewById(R.id.selection);
}
public void onListItemClick(ListView parent, View v,
int position, long id) {
selection.setText(items[position]);
}
}
This follows the general structure for the previous ListView
sample. The key difference here is that we have told ArrayAdapter
that we want to use our custom layout (R.layout.row
) and that the TextView
where the word should go is known as R.id.label
within that custom layout.
NOTE: Remember that to reference a layout (row.xml
), use R.layout
as a prefix on the base name of the layout XML file (R.layout.row
).
The result is a ListView
with icons down the left side; in this example, all the icons are the same, as shown in Figure 13–1.
As shown in the previous section, the technique of supplying an alternative layout to use for rows handles simple cases very nicely. However, what if we want the icon to change based on the row data? For example, suppose we want to use one icon for small words and a different icon for large words. In the case of ArrayAdapter
, we will need to extend it, creating our own custom subclass (e.g., IconicAdapter
) that incorporates our business logic. In particular, it will need to override getView()
.
The getView()
method of an Adapter
is what an AdapterView
(like ListView
or Spinner
) calls when it needs the View
associated with a given piece of data the Adapter
is managing. In the case of an ArrayAdapter
, getView()
is called as needed for each position in the array—“get me the View
for the first row,” “get me the View
for the second row,” and so forth.
As an example, let’s rework the code in the preceding section to use getView()
, so we can show different icons for different rows—in this case, one icon for short words and one for long words (from the FancyLists/Dynamic
sample project):
public class DynamicDemo extends ListActivity {
TextView selection;
private static final 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 IconicAdapter());
selection=(TextView)findViewById(R.id.selection);
}
public void onListItemClick(ListView parent, View v,
int position, long id) {
selection.setText(items[position]);
}
class IconicAdapter extends ArrayAdapter<String> {
IconicAdapter() {
super(DynamicDemo.this, R.layout.row, R.id.label, items);
}
public View getView(int position, View convertView,
ViewGroup parent) {
View row=super.getView(position, convertView, parent);
ImageView icon=(ImageView)row.findViewById(R.id.icon);
if (items[position].length()>4) {
icon.setImageResource(R.drawable.delete);
}
else {
icon.setImageResource(R.drawable.ok);
}
return(row);
}
}
}
Our IconicAdapter
—an inner class of the activity—has two methods. First, it has the constructor, which simply passes to ArrayAdapter
the same data we used in the ArrayAdapter
constructor in StaticDemo
. Second, it has our getView()
implementation, which does two things:
getView()
, which returns to us an instance of our row View
, as prepared by ArrayAdapter
. In particular, our word has already been put into the TextView
, since ArrayAdapter
does that normally.ImageView
and applies a business rule to set which icon should be used, referencing one of two drawable resources (R.drawable.ok
and R.drawable.delete
).The result of our revised example is shown in Figure 13–2.
The preceding version of the DynamicDemo
application works fine. However, sometimes ArrayAdapter
cannot be used even to set up the basics of our row. For example, it is possible to have a ListView
where the rows are materially different, such as category headers interspersed among regular rows. In that case, we may need to do all the work ourselves, starting with inflating our rows. We will do that after a brief introduction to inflation.
“Inflation” means the act of converting an XML layout specification into the actual tree of View
objects the XML represents. This is undoubtedly a tedious bit of code: take an element, create an instance of the specified View
class, walk the attributes, convert those into property setter calls, iterate over all child elements, lather, rinse, and repeat.
The good news is that the fine folks on the Android team wrapped up all that into a class called LayoutInflater
, which we can use ourselves. When it comes to fancy lists, for example, we want to inflate a View
for each row shown in the list, so we can use the convenient shorthand of the XML layout to describe what the rows are supposed to look like.
For example, let’s look at a slightly different implementation of the DynamicDemo
class, from the FancyLists/DynamicEx
project:
public class DynamicDemo extends ListActivity {
TextView selection;
private static final 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 IconicAdapter());
selection=(TextView)findViewById(R.id.selection);
}
public void onListItemClick(ListView parent, View v,
int position, long id) {
selection.setText(items[position]);
}
class IconicAdapter extends ArrayAdapter<String> {
IconicAdapter() {
super(DynamicDemo.this, R.layout.row, items);
}
public View getView(int position, View convertView,
ViewGroup parent) {
LayoutInflater inflater=getLayoutInflater();
View row=inflater.inflate(R.layout.row, parent, false);
TextView label=(TextView)row.findViewById(R.id.label);
label.setText(items[position]);
ImageView icon=(ImageView)row.findViewById(R.id.icon);
if (items[position].length()>4) {
icon.setImageResource(R.drawable.delete);
}
else {
icon.setImageResource(R.drawable.ok);
}
return(row);
}
}
}
Here we inflate our R.layout.row
layout by use of a LayoutInflater
object, obtained from our Activity
via getLayoutInflater()
. This gives us a View
object back, which, in reality, is our LinearLayout
with an ImageView
and a TextView
, just as R.layout.row
specifies. However, rather than having to create all those objects ourselves and wire them together, the XML and LayoutInflater
handle the “heavy lifting” for us.
So we have used LayoutInflater
to give us a View
representing the row. This row is “empty,” since the static layout file has no idea what actual data goes into the row. It is our job to customize and populate the row as we see fit before returning it, as follows:
ImageView
icon widget and replace the stock resource with a different oneThe user sees nothing different—we have simply changed how those rows are being created. Obviously, this was a fairly contrived example, but you can see that this technique could be used to customize rows based on any sort of criteria.
The getView()
implementation shown in the FancyLists/DynamicEx
project works, but it’s inefficient. Every time the user scrolls, we have to create a bunch of new View
objects to accommodate the newly shown rows. This is bad in terms of both overhead and perceived performance.
It might be bad for the immediate user experience if the list appears to be sluggish. More likely, though, it will be bad due to battery usage—every bit of CPU that is used eats up the battery. This is compounded by the extra work the garbage collector needs to do to get rid of all those extra objects we create. So the less efficient our code, the more quickly the phone’s battery will be drained, and the less happy the user will be. And we want happy users, right?
So, let’s take a look at a few tricks to make our fancy ListView
widgets more efficient.
The getView()
method receives, as one of its parameters, a View
named, by convention, convertView
. Sometimes, convertView
will be null
. In those cases, we need to create a new row View
from scratch (e.g., via inflation), just as we did in the previous example. However, if convertView
is not null
, then it is actually one of our previously created View
objects! This will happen primarily when the user scrolls the ListView
. As new rows appear, Android will attempt to recycle the views of the rows that scrolled off the other end of the list, to save us from having to rebuild them from scratch.
Assuming that each of our rows has the same basic structure, we can use findViewById()
to get at the individual widgets that make up our row and change their contents, and then return convertView
from getView()
, rather than create a whole new row. For example, here is the getView()
implementation from the earlier example, now optimized via convertView
(from the FancyLists/Recycling
project):
public class RecyclingDemo extends ListActivity {
private TextView selection;
private static final 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 IconicAdapter());
selection=(TextView)findViewById(R.id.selection);
}
public void onListItemClick(ListView parent, View v,
int position, long id) {
selection.setText(items[position]);
}
class IconicAdapter extends ArrayAdapter<String> {
IconicAdapter() {
super(RecyclingDemo.this, R.layout.row, items);
}
public View getView(int position, View convertView,
ViewGroup parent) {
View row=convertView;
if (row==null) {
LayoutInflater inflater=getLayoutInflater();
row=inflater.inflate(R.layout.row, parent, false);
}
TextView label=(TextView)row.findViewById(R.id.label);
label.setText(items[position]);
ImageView icon=(ImageView)row.findViewById(R.id.icon);
if (items[position].length()>4) {
icon.setImageResource(R.drawable.delete);
}
else {
icon.setImageResource(R.drawable.ok);
}
return(row);
}
}
}
Here, we check to see if the convertView
is null
. If so, we inflate our row; otherwise, we just reuse it. The work to fill in the contents (icon image and text) is the same in either case. The advantage is that we avoid the potentially expensive inflation step. In fact, according to statistics cited by Google at the 2010 Google I|O conference, a ListView
that uses a recycling ListAdapter
will perform 150 percent faster than one that does not. For complex rows, that might even understate the benefit.
Not only is this faster, but it uses much less memory. Each widget or container—in other words, each subclass of View
—holds onto up to 2kB of data, not counting things like images in ImageView
widgets. Each of our rows, therefore, might be as big as 6kB. For our list of 25 nonsense words, consuming as much as 150kB for a nonrecycling list (25 rows at 6kB each) would be inefficient but not a huge problem. A list of 1000 nonsense words, though, consuming as much as 6MB of RAM, would be a much bigger issue. Bear in mind that your application may have only 16MB of Java heap memory to work with, especially if you are targeting older devices with constrained resources. Recycling allows us to handle arbitrary list lengths with only as much View
memory consumed as is needed for the rows visible onscreen.
Note that row recycling is an issue only if we are creating the rows ourselves. If we let ArrayAdapter
create the rows, by leveraging its implementation of getView()
, as shown in the FancyLists/Dynamic
project, then it deals with the recycling.
Another somewhat expensive operation commonly done with fancy views is calling findViewById()
. This dives into our inflated row and pulls out widgets by their assigned identifiers, so we can customize the widget contents (e.g., to change the text of a TextView
or change the icon in an ImageView
). Since findViewById()
can find widgets anywhere in the tree of children of the row’s root View
, this could take a fair number of instructions to execute, particularly if we need to find the same widgets repeatedly.
In some GUI toolkits, this problem is avoided by having the composite View
objects, like rows, be declared totally in program code (in this case, Java). Then, accessing individual widgets is merely a matter of calling a getter or accessing a field. And we can certainly do that with Android, but the code gets rather verbose. What would be nice is a way that enables us still to use the layout XML, yet cache our row’s key child widgets so that we need to find them only once. That’s where the holder pattern comes into play, in a class we’ll call ViewHolder
.
All View
objects have getTag()
and setTag()
methods. These allow us to associate an arbitrary object with the widget. The holder pattern uses that “tag” to hold an object that, in turn, holds each of the child widgets of interest. By attaching that holder to the row View
, every time we use the row, we already have access to the child widgets we care about, without having to call findViewById()
again.
So, let’s take a look at one of these holder classes (taken from the FancyLists/ViewHolder
sample project):
package com.commonsware.android.fancylists.five;
import android.view.View;
import android.widget.ImageView;
class ViewHolder {
ImageView icon=null;
ViewHolder(View base) {
this.icon=(ImageView)base.findViewById(R.id.icon);
}
}
ViewHolder
holds onto the child widgets, initialized via findViewById()
in its constructor. The widgets are simply package-protected data members, accessible from other classes in this project, such as a ViewHolderDemo
activity. In this case, we are holding onto only one widget—the icon—since we will let ArrayAdapter
handle our label for us.
Using ViewHolder
is a matter of creating an instance whenever we inflate a row and attaching said instance to the row View
via setTag()
, as shown in this rewrite of getView()
, found in ViewHolderDemo
:
public View getView(int position, View convertView,
ViewGroup parent) {
View row=super.getView(position, convertView, parent);
ViewHolder holder=(ViewHolder)row.getTag();
if (holder==null) {
holder=new ViewHolder(row);
row.setTag(holder);
}
if (getModel(position).length()>4) {
holder.icon.setImageResource(R.drawable.delete);
}
else {
holder.icon.setImageResource(R.drawable.ok);
}
return(row);
}
Here, we go back to allowing ArrayAdapter
to handle our row inflation and recycling for us. If the call to getTag()
on the row returns null
, we know we need to create a new ViewHolder
, which we then attach to the row via setTag()
for later reuse. Then, accessing the child widgets is merely a matter of accessing the data members on the holder. The first time the ListView
is displayed, all new rows need to be inflated, and we wind up creating a ViewHolder
for each. As the user scrolls, rows get recycled, and we can reuse their corresponding ViewHolder
widget caches.
Using a holder helps performance, but the effect is not as dramatic. Whereas recycling can give you a 150 percent performance improvement, adding in a holder increases the improvement to 175 percent. Hence, while you may wish to implement recycling up front when you create your adapter, adding in a holder might be something you deal with later, when you are working specifically on performance tuning.
In this particular case, we certainly could simplify all of this by skipping ViewHolder
and using getTag()
and setTag()
with the ImageView
directly. This example is written as it is to demonstrate how to handle a more complex scenario, where you might have several widgets that would need to be cached via the holder pattern.
Lists with pretty icons next to them are all fine and well. But, can we create ListView
widgets whose rows contain interactive child widgets instead of just passive widgets like TextView
and ImageView
? For example, there is a RatingBar
widget that allows users to assign a rating by clicking on a set of star icons. Could we combine the RatingBar
with text to allow people to scroll a list of, say, songs and rate them right inside the list? There is good news and bad news.
The good news is that interactive widgets in rows work just fine. The bad news is that it is a little tricky, specifically when it comes to taking action when the interactive widget’s state changes (e.g., a value is typed into a field). We need to store that state somewhere, since our RatingBar
widget will be recycled when the ListView
is scrolled. We need to be able to set the RatingBar
state based on the actual word being viewed as the RatingBar
is recycled, and we need to save the state when it changes so it can be restored when this particular row is scrolled back into view.
What makes this interesting is that, by default, the RatingBar
has absolutely no idea which item in the ArrayAdapter
it represents. After all, the RatingBar
is just a widget, used in a row of a ListView
. We need to teach the rows which item in the ArrayAdapter
they are currently displaying, so when their RatingBar
is checked, they know which item’s state to modify.
So, let’s see how this is done, using the activity in the FancyLists/RateList
sample project. We will use the same basic classes that we used in our previous example. We are displaying a list of nonsense words, which can then be rated. In addition, words given a top rating are put in all caps.
package com.commonsware.android.fancylists.six;
import android.app.Activity;
import android.os.Bundle;
import android.app.ListActivity;
import android.view.View;
import android.view.ViewGroup;
import android.view.LayoutInflater;
import android.widget.AdapterView;
import android.widget.ArrayAdapter;
import android.widget.RatingBar;
import android.widget.LinearLayout;
import android.widget.ListView;
import android.widget.TextView;
import java.util.ArrayList;
public class RateListDemo extends ListActivity {
private static final 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);
ArrayList<RowModel> list=new ArrayList<RowModel>();
for (String s : items) {
list.add(new RowModel(s));
}
setListAdapter(new RatingAdapter(list));
}
private RowModel getModel(int position) {
return(((RatingAdapter)getListAdapter()).getItem(position));
}
class RatingAdapter extends ArrayAdapter<RowModel> {
RatingAdapter(ArrayList<RowModel> list) {
super(RateListDemo.this, R.layout.row, R.id.label, list);
}
public View getView(int position, View convertView,
ViewGroup parent) {
View row=super.getView(position, convertView, parent);
ViewHolder holder=(ViewHolder)row.getTag();
if (holder==null) {
holder=new ViewHolder(row);
row.setTag(holder);
RatingBar.OnRatingBarChangeListener l=
new RatingBar.OnRatingBarChangeListener() {
public void onRatingChanged(RatingBar ratingBar,
float rating,
boolean fromTouch) {
Integer myPosition=(Integer)ratingBar.getTag();
RowModel model=getModel(myPosition);
model.rating=rating;
LinearLayout parent=(LinearLayout)ratingBar.getParent();
TextView label=(TextView)parent.findViewById(R.id.label);
label.setText(model.toString());
}
};
holder.rate.setOnRatingBarChangeListener(l);
}
RowModel model=getModel(position);
holder.rate.setTag(new Integer(position));
holder.rate.setRating(model.rating);
return(row);
}
}
class RowModel {
String label;
float rating=2.0f;
RowModel(String label) {
this.label=label;
}
public String toString() {
if (rating>=3.0) {
return(label.toUpperCase());
}
return(label);
}
}
}
The following list explains what is different in this activity and getView()
implementation from before:
String
[] items as the list of nonsense words, but instead of pouring that String
array straight into an ArrayAdapter
, we turn it into a list of RowModel
objects. RowModel
is the mutable model: it holds the nonsense word plus the current checked state. In a real system, these might be objects populated from a database, and the properties would have more business meaning.onListItemClick()
to reflect the change from a pure-String
model to use a RowModel
.ArrayAdapter
subclass (RatingAdapter
), in getView()
, lets ArrayAdapter
inflate and recycle the row, and then checks to see if we have a ViewHolder
in the row’s tag. If not, we create a new ViewHolder
and associate it with the row. For the row’s RatingBar
, we add an anonymous onRatingChanged()
listener that looks at the row’s tag (getTag()
) and converts that into an Integer
, representing the position within the ArrayAdapter
that this row is displaying. Using that, the rating bar can get the actual RowModel
for the row and update the model based on the new state of the rating bar. It also updates the text adjacent to the RatingBar
when checked, to match the rating bar state.RatingBar
has the proper contents and has a tag (via setTag()
) pointing to the position in the adapter the row is displaying.The row layout is very simple, just a RatingBar
and a TextView
inside a LinearLayout
:
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:orientation="horizontal"
>
<RatingBar
android:id="@+id/rate"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:numStars="3"
android:stepSize="1"
android:rating="2" />
<TextView
android:id="@+id/label"
android:padding="2dip"
android:textSize="18sp"
android:layout_gravity="left|center_vertical"
android:layout_width="fill_parent"
android:layout_height="wrap_content"/>
</LinearLayout>
The ViewHolder
is similarly simple, just extracting the RatingBar
out of the row View
for caching purposes:
package com.commonsware.android.fancylists.six;
import android.view.View;
import android.widget.RatingBar;
class ViewHolder {
RatingBar rate=null;
ViewHolder(View base) {
this.rate=(RatingBar)base.findViewById(R.id.rate);
}
}
And the result is what you would expect, visually, as shown in Figure 13–3.
Figure 13–4 shows a toggled rating bar turning its word into all caps.