Fancy ListViews, Part Three

In our last episode, we saw how we could save processing time — and, hence, battery life — by recycling existing row views in our fancy lists, simply by checking and reusing the convertView parameter passed into our getView().

In his comment to this series’ initial post, Romain Guy also left a bit of code that uses something called ViewHolder. Today, let’s take a look at this technique, with a twist.

The goal, once again, is to reduce the amount of work it takes to render one of our fancy lists, both so users get snappier response and so we don’t drain the battery so quickly. Recycling views saves us constructing new rows from whole cloth, particularly important when we are using ViewInflate and creating them from an XML layout.

Another somewhat expensive operation we do a lot with fancy views is call findViewById(). This dives into our inflated row and pulls out widgets by their assigned identifiers, so we can customize the widget contents (e.g., change the text of a TextView, 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 keep having to re-find widgets we had found once before.

In some GUI toolkits, this problem is avoided by having the composite Views, like our rows, be declared totally in program code (in this case, Java). Then, accessing individual widgets is merely the matter of calling a getter or accessing a field. And you can certainly do that with Android, but the code gets rather verbose. What would be nice is a way where we can still use the layout XML yet cache our row’s key child widgets so we only have to find them once.

That’s where ViewHolder comes in…or, in this post, a variation I’m calling ViewWrapper.

All View objects have getTag() and setTag() methods. These allow you to associate an arbitrary object with the widget. What the holder pattern does is use 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:

1. class ViewWrapper {
2. View base;
3. TextView label=null;
4. ImageView icon=null;
6. ViewWrapper(View base) {
7. this.base=base;
8. }
10. TextView getLabel() {
11. if (label==null) {
12. label=(TextView)base.findViewById(R.id.label);
13. }
15. return(label);
16. }
18. ImageView getIcon() {
19. if (icon==null) {
20. icon=(ImageView)base.findViewById(R.id.icon);
21. }
23. return(icon);
24. }
25. }

class ViewWrapper {  View base;  TextView label=null;  ImageView icon=null;   ViewWrapper(View base) {   this.base=base;  }   TextView getLabel() {   if (label==null) {    label=(TextView)base.findViewById(R.id.label);   }    return(label);  }   ImageView getIcon() {   if (icon==null) {    icon=(ImageView)base.findViewById(R.id.icon);   }    return(icon);  } } 

The main difference between ViewWrapper (shown above) and ViewHolder (shown in the comment to this post) is that ViewWrapper lazy-finds the child widgets. If you create a wrapper and never need a specific child, you never go through the findViewById() operation for it and never have to pay for those CPU cycles. On the flip side, ViewHolder has the child widgets in public fields, whereas ViewWrapper uses getter methods, so there are going to be situations where a ViewHolder approach is more efficient.

The holder pattern also:

• Allows us to consolidate all our per-widget type casting in one place, rather than having to cast it everywhere we call findViewById()

• Perhaps track other information about the row, such as state information we are not yet ready to “flush” to the underlying model — more on this in an upcoming post

Using ViewWrapper 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 last post’s demo’s getView() method:

1. public View getView(int position, View convertView, ViewGroup parent) {
2. View row=convertView;
3. ViewWrapper wrapper=null;
5. if (row==null) {
6. ViewInflate inflater=context.getViewInflate();
8. row=inflater.inflate(R.layout.row, null, null);
9. wrapper=new ViewWrapper(row);
10. row.setTag(wrapper);
11. }
12. else {
13. wrapper=(ViewWrapper)row.getTag();
14. }
16. wrapper.getLabel().setText(getModel(position));
18. if (getModel(position).length()>4) {
19. wrapper.getIcon().setImageResource(R.drawable.delete);
20. }
22. return(row);
23. }

public View getView(int position, View convertView, ViewGroup parent) {  View row=convertView;  ViewWrapper wrapper=null;   if (row==null) {   ViewInflate inflater=context.getViewInflate();    row=inflater.inflate(R.layout.row, null, null);   wrapper=new ViewWrapper(row);   row.setTag(wrapper);  }  else {   wrapper=(ViewWrapper)row.getTag();  }   wrapper.getLabel().setText(getModel(position));   if (getModel(position).length()>4) {   wrapper.getIcon().setImageResource(R.drawable.delete);  }    return(row); } 

Just as we check convertView to see if it is null in order to create the row Views as needed, we also pull out (or create) the corresponding row’s ViewWrapper. Then, accessing the child widgets is merely a matter of calling their associated methods on the wrapper.

Many thanks to Romain Guy for pointing out this technique!

In our next episode, we’ll look at putting interactive widgets in a row, not just static ones like TextView and ImageView, and discuss making modifications to the state that supplies the data for the list itself.