getViewTypeCount and getItemViewType methods of ArrayAdapter

Question

Can somebody in plain words explain me the usage of getViewTypeCount() and getItemViewType() methods of ArrayAdapter?

Disengage

Answer 1

These handle the case where you want different types of view for different rows. For instance, in a contacts application you may want even rows to have pictures on the left side and odd rows to have pictures on the right. In that case, you would use:

@Override
public int getViewTypeCount() {
    return 2;
}

@Override
public int getItemViewType(int position) {
    return position % 2;
}

The framework uses your view type to decide which views to hand you via convertView in your getView method. In other words, in the above example, your even rows will only get recycled views with pictures on the left side to reuse, and odd rows will only get ones with pictures on the right.

If every row in your list has the same layout, you don't need to worry about view types. In fact, BaseAdapter.java provides a default behavior for all adapters:

public int getItemViewType(int position) {
    return 0;
}

public int getViewTypeCount() {
    return 1;
}

This indeed provides you with the same view type for every row.

Edit - to outline the general flow:

1. You bind data to your AdapterView using an adapter.
2. The AdapterView tries to display items that are visible to the user.
3. The framework calls getItemViewType for row n, the row it is about to display.
4. The framework checks its recycled views pool for views of row n's type. It doesn't find any because no views have been recycled yet.
5. getView is called for row n.
6. You call getItemViewType for row n to determine what type of view you should use.
7. You use an if/switch statement to inflate a different xml file depending on which view type is required.
8. You fill the view with information.
9. You return the view, exiting getView, and your row's view is displayed to the user.

Now, when a view is recycled by scrolling off the screen it goes into a recycled views pool that is managed by the framework. These are essentially organized by view type so that a view of the correct type is given to you in convertView parameter in your getView method:

1. The framework again calls getItemViewType for the row it wants to display.
2. This time, there is a view in the recycled pool of the appropriate type.
3. The recycled view is passed to you as the convertView parameter to your getView method.
4. You fill the recycled view with new information and return it.

Abettor

@Matthew, thanks for your answer. Can you describe the flow how these methods are invoked. Also I don't understand how this is actually associated with my data in res/layout. – Disengage

There isn't an explicit contract for when these methods are invoked. res/layout is the place for view objects. This is an adapter. You should check the item type in your getView method and inflate the proper view from res/layout accordingly. – Abettor

You are returning it yourself in getItemViewType. – Abettor

You do the association manually in getView: if (type == 0) { /* inflate R.layout.row_icon_on_left / } else { / inflate R.layout.row_icon_on_right */ } – Abettor

You could also return the layout you want to use as your view type for simplicity, since it is also an int. – Abettor

Beware! getItemViewType() must return an int between 0 and getViewTypeCount() - 1. – Hulse

good answer, can you please share the docs supporting your explaination? – Encephalomyelitis

If you were hoping to use this with a Spinner, you're out of luck: "On API LOLLIPOP and above, attempting to set an adapter with more than one view type will throw an IllegalArgumentException" developer.android.com/reference/android/widget/… – Saulsauls

Thank you for this answer. Especially, the description of the flow particularly helped clear the confusions in my mind. – Timetable

@MatthewWillis can explain how to implement getItemId with setHasStableIds. – Humdrum

As @PacificSky, said and is written in developer.android.com/reference/android/widget/…: Note: Integers must be in the range 0 to getViewTypeCount() - 1. IGNORE_ITEM_VIEW_TYPE can also be returned. I didn't know that and used numbers from 1 to getViewTypeCount(). In onCreateViewHolder(ViewGroup viewGroup, int viewType) you receive a viewType that is set by getItemViewType(int position). Strange, but it works in my case. In https://mcmap.net/q/149648/-getviewtypecount-and-getitemviewtype-methods-of-arrayadapter Randika Vishman wrote it might be a problem with jumbling, but I didn't see it. – Subdelirium

Answer 2

If we need to show different type of view in list-view then its good to use getViewTypeCount() and getItemViewType() in adapter instead of toggling a view View.GONE and View.VISIBLE can be very expensive task inside getView() which will affect the list scroll.

Please check this one for use of getViewTypeCount() and getItemViewType() in Adapter.

Link : the-use-of-getviewtypecount

Forefoot

Returning IGNORE_ITEM_VIEW_TYPE in getItemViewType() will always pass 'view' as null in getView(int position, View view, ViewGroup viewGroup) forcing to initialize all the UI components. Is not that a bad performance indicator wherein in case of holder pattern, we get to reuse existing UI views and we can simply toggle the view to View.GONE or View.VISIBLE based on position. – Armendariz

Answer 3

Watch Outttt!!!!
I had to face for a problem implementing a ListView yesterday and it's two types of views for rows got jumbled just after I scroll it. Even though the top voted answer within this thread gives a good general explanation it hasn't highlighted the most important bit of information to stop the above UI bug which I have mentioned.

Here is my explanation:
Both getViewTypeCount() and getItemViewType() are being used by BaseAdapter's getView method to find out which type of a view should it be fetch, recycled and returned. (as explained in the top answer within the thread). But if you don't implement these two methods intuitively according to the Android API Doc, then you might get into the problem I mentioned about.

Summarized Guideline for the implementation:
To implement multiple types of Views for ListView's rows we have to essentially implement, getItemViewType() and getViewTypeCount() methods. And getItemViewType() documentation gives us a Note as follows:

Note: Integers must be in the range 0 to getViewTypeCount() - 1. IGNORE_ITEM_VIEW_TYPE can also be returned.

So in your getItemViewType() you should return values for the View Type, starting from 0, to the last type as (number of types - 1). For example, let's say you only have three types of views? So depending on the data object for the view, you could only return 0 or 1 or 2 from the getItemViewType() method, like a zero-based array index. And as you have three types of views used, your getViewTypeCount() method must return 3.

In any case if you return any other integer values like 1, 2, 3 or 111, 222, 333 for this method you definitely might experience the above UI bug which you just placed by not obeying to the Android API Doc.

If you didn't get the clue or couldn't still resolve and need further information please read my detailed answer within this StackOverflow Q&A thread.

Read the Android Developer Doc for further information you might be find the clue directly.

Hope this answer might be helpful to someone out there to save a lots of hours!!!

Cheers!!!

Scharff

Thanks for mentionning IGNORE_ITEM_VIEW_TYPE I had a bug on one of my ListView. I used an ArrayAdapter to insert a view composed of 1 image and 2 text view. I had only one view type. I tried either to not Override the method getItemViewType, or to Override it by returning the position or a hard-coded integer. In all cases, I was experiencing duplicates in my list, with odd behaviour when scrolling (duplicates changes). Returning IGNORE_ITEM_VIEW_TYPE in the method fixed the issue. Thanks. – Manaus

@Manaus glad it was helpful for you! :-) – Scharff