ViewHolder vs HolderView

Adapters and recycling
The reason for having a ViewHolder or HolderView is to improve performance of AdapterViews. Adapters used by AdapterViews recycles the views that the AdapterView is using to display content. More about that can be read here.

For refference a short explanation of the ViewHolder pattern can be found here.

HolderView
The HolderView object inherits from a View of some sort, in the example a GridLayout since that was what the layout was using before being replaced that with a “merge” tag. A HolderView stores references to the component views, just like a ViewHolder, to avoid the expensive findViewById() look-up. But unlike the ViewHolder the HolderView takes the responsibility to bind data to its child views when asked to do so. This makes for a smaller Adapter that are easier to understand and maintain, typically the getView(…) method would look something like:

    @Override
    public View getView(int i, View convertView, ViewGroup viewGroup) {
        HolderView holderView;
        // Important to not just null check, but rather to a instanceof
        // since we might get any subclass of view here.
        if (convertView instanceof HolderView) {
            holderView = (HolderView) convertView;
        } else {
            holderView = new HolderView(mContext);
        }
        holderView.bind(new Digit(i));

        return holderView;
    }

and the HolderView object would look something similar to:

public class HolderView extends GridLayout {

    private TextView mDigitDigit;
    private String mDigitText;

    public HolderView(Context context, AttributeSet attrs) {
        super(context, attrs);
        View v = LayoutInflater.from(context).inflate(R.layout.list_detail, this);
        mDigitDigit = (TextView) v.findViewById(R.id.list_detail_digit);
        mDigitText = context.getResources().getString(R.string.list_detail_digit);
    }

    public void bind(Digit digit) {
        mDigitDigit.setText(String.format(mDigitText, digit));
    }
}

Below are links to an example project on github where you will find two branches, one for a ViewHolder example and one for a HolderView example.

So essentially the two approaches are very similar and solves the same problem. The main difference is that the responsibility of populating the ui is moved from the Adapter to the view itself.

This Post Has 7 Comments

  1. Thanks, Good Article and very useful to me.

    1. Happy to hear that you like it!

  2. But what works faster ViewHolder or HolderView?

    1. Performance should be the same, but I have not measured to see if there might be any difference. The purpose however, is not to gain performance, just to improve readability of the adapter class (that often grows to a large monster as soon as some logic is needed to determine what to show). If you do run some tests to see if there is any difference in performance, please post the results here for others to learn from!

  3. Sorry, I’m not following HolderView. First, why is it extending GridLayout when your example is a ListView? If this improves readability of the adapter, it adds the complexity of a HolderView class, I presume one for every AdapterView in your application? The ViewHolder is “ugly” because the traditional one promoted by the Google Android documentation requires a static ViewHolder class for every Adapter. I much prefer the new and improved ViewHolder. See last post here: https://code.google.com/p/android/issues/detail?id=18273

    This both simplifies the adapter (IMO), and I don’t have to create any other new classes (other than that one ViewHolder).

    Thoughts?

    1. Hi Mark,
      The GridLayout is used for each element of the ListView to organize/layout the contents of each item in the list. Might look a bit weird since i don’t define the GridLayout in the xml files, but just inflate it from the HolderView class (that extends GridLayout).
      I did have a look at the post you linked to, I do agree with them 100%, that’s a much better way to deal with the ViewHolder.
      The HolderView is another way of solving the same problem, and at the same time moving code that deals with layout from the adapter to the view. That last part is what I really like about the HolderView approach, moving the responsibility for layout/looks from the adapter to the view object.
      Not sure if this answers your questions?

  4. Hello sir, I use ViewHolder pattern and currently i have requirement like one row have dynamic subview.

    I have posted my question on stackoverflow.

    (http://stackoverflow.com/q/23127485/1318946)

    I have implemented SubViewHolder in ViewHolder class but i am getting problem of View.

    Please check and reply me.

    Thanks & Regards,

    Pratik Butani.

Leave a Reply

Close Menu