Android: Use the ViewHolder Luke, and Larry, and Curly, and Moe

This is going to be a quick hit blog post about the Android "ViewHolder" pattern. This is a pattern that many people seem to be at least vaguely familiar with, but not very many actually use (based on open source Android applications and examples/books, etc.).

First some background. Larry, Moe, and Curly were characters from . . . ok, not that much background, but to really make use of the ViewHolder with Android you do need to know what the ListView widget is (a helper for managing views of lists), and that ListViews and generally backed by Adapters (adapters provide data for lists and build views for said data, they can be made from lists of stuff in files, or from in memory arrays, or from databases, and so on).

An example of a ListView in action is seen in the screen shot below.

This screen is taken from the DevNexus 2010 demo application I wrote for a conference I attended and spoke at this year. This particular ListView is basically a navigable list of the presentation abstracts and speakers. We will look at the code behind this screen, complete with ViewHolder, coming up. First a bit more background.

You are probably at least vaguely familiar with ListView/Adapter and the related concepts if you have done any Android development at all. ListView is *very* powerful and helpful widget. Nevertheless, ListView's are often misused and abused because there are so many options and settings and patterns that surround them. I don't have time to go into great depth on ListView itself, but for the quick hit I promised I want to address 2 key things to keep in mind when working with ListViews:

• Creating views is expensive, you don't want to inflate or manually create new views for every view on the list. ListView can re-use views, if you let it.
• Even if you are re-using views, you also don't want to find child views by id (findViewById) every time, because that is expensive too.

I would say that 90% of Android examples or open source apps I see (or developers I talk to) do the first item there properly. Depending on the adapter in play they are re-using views. It's pretty simple, use the "convertView" on simple adapters like ArrayAdapter (which we will see coming up) and use the "newView" on more involved adapters like CursorAdapter. I would also say that the same high percentage of examples and open source apps *do not* use the ViewHolder to avoid trips to findViewById. If your list is small, this might not be a big deal, but if the list is large it can make a difference in terms of frame rate, resource usage, and performance (which equals better experience for the user, longer battery life, etc.). Also, it's a good habit to be in even with small lists, more efficient code is better, especially on a mobile platform.

So how do you do this stuff? Well, here is the Adapter from the aforementioned DevNexus 2010 application to demonstrate:

01	static class ViewHolder {

02	private TextView view1;

03	private TextView view2;

04

}

05

06	private class PresentationAdapter extends ArrayAdapter<Presentation&g<wbr>t; {

07

08	LayoutInflater vi = (LayoutInflater) PresentationList.this.getSyste<wbr>mService(Context.LAYOUT_INFLAT<wbr>ER_SERVICE);

09	private final ArrayList<Presentation> presentations;

10

11	public PresentationAdapter(final Context context, final int resId, final ArrayList<Presentation> presentations) {

12	super(context, resId, presentations);

13	this.presentations = presentations;

14

}

15

16

@Override

17	public View getView(final int position, final View convertView, final ViewGroup parent) {

18	// re-use the convertView, try not to recreate objects here or inflate every time (expensive)

19	// also use the "tag" with the "view holder" pattern to avoid findViewById every time

20	View v = convertView;

21	if (v == null) {

22	v = vi.inflate(R.layout.list_items<wbr>_item, null);

23	ViewHolder viewHolder = new ViewHolder();

24	viewHolder.view1 = (TextView) v.findViewById(R.id.list_item_<wbr>above);

25	viewHolder.view2 = (TextView) v.findViewById(R.id.list_item_<wbr>below);

26	v.setTag(viewHolder);

27

}

28

29	Presentation p = presentations.get(position);

30	if (p != null) {

31	ViewHolder viewHolder = (ViewHolder) v.getTag();

32	viewHolder.view1.setText(p.nam<wbr>e);

33	viewHolder.view2.setText(p.spe<wbr>aker);

34

}

35

return v;

36

}

37

}

The complete code for the DevNexus application (for context), is here. What we are focusing on above is the Adapter to the ListView. Within it we see that we are making use of the convertView if present to grab our subsequent views, and to populate our own internal ViewHolder representation. If the convertView isn't present, then we do the extra work of inflating our views and building our ViewHolder.

The "convertView" is a convenient helper object provided to you by the framework specifically for re-use (if the framework is ready to provide it, the first item in the list will have a null convertView, hence the check, and the work only if it is null). The framework knows the views that are passing by, and as it recycles them it hands you one that you can "convert."

So what is the ViewHolder? Well, that's really just a simple object we have created (using a package scoped inner class) that stores child views (though you could store anything there, that is all we need for this example). View objects have a "Tag" property that you can use to store any object. If you are getting recycled views anyway, it's very easy and helpful to just stick child views you need *there* and retrieve later, as opposed to calling "findViewById" to pull views from resources for every view in the list. Really this just saves us the findViewById calls. That might not seem like much, but again, in large lists it can cut down on overhead.

A little further down in the code, after we get past creating the convertView in the case that it's null, we see where we use the ViewHolder to get a reference to our subsequent child views, and set stuff (in this case just Strings, but could be anything).

This is a simple example, and I certainly won't promise that it's perfect, but hopefully it does help to explain what ViewHolder is, and why it's useful (and a little about re-cycling views in general).

Comments

Alternative to the ViewHolder

Submitted by Uncle Code Monkey (not verified) on Tue, 12/21/2010 - 10:54.

Thanks for writing on this subject. In the past, I did not bother with caching the find results and after reading this blog, I decided to give it a try and see if it improves the speed of my app any. I noticed my app become more responsive and that's all the convincing I need to keep it.

I do, however, have a different approach to caching than how you wrote this article. Instead of keeping a separate class in which to store the result of the various finds, I just store it directly into the View.tag mechanism like so:

1	protected Object getViewHandle(View aParentView, int aViewToFind) {

2	Object v = aParentView.getTag(aViewToFind<wbr>);

3	if (v==null) {

4	v = aParentView.findViewById(aView<wbr>ToFind);

5	aParentView.setTag(aViewToFind<wbr>,v);

6

}

7

return v;

8

}

and then call it in my code by

1	TextView tv = (TextView)getViewHandle(itemVi<wbr>ew,R.id.some_text_view);

This way I don't need to define classes for each kind of item view in the list and makes the technique easily adaptable for different lists without introducing another class that needs to be passed around to all the code that works with such views.

Thanks for the inspiration!