getViewTypeCount and getItemViewType methods of ArrayAdapter

Question

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

Answer 1

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

Answer 2

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!!!

Answer 3

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.