1

I have a ListView in my app that is used to show a list with 2 types of items. The way it is currently implemented is that I have two different XML layouts for each of the item types, my adapter correctly reports the type and in the getView() method I inflate the appropriate XML according the the type in the specified position.

The problem is that in the vast majority of cases the structure of the list of items is that most of the type 1 items are in the beginning and most of the type 2 items are in the end, so usually at first you see mostly type 1 items, you scroll down and at some point you start seeing type 2 items, and they continue until the end of the list.

All works fine while I scroll until I hit that midpoint. Around that point all the calls to getView() get null passed as the convertView parameter. This makes sense obviously. The problem is that is seems like ListView stores all the previous type 1 views in the recycler, and I will not use them as long as I keep scrolling down since from now on most of the views will be type 2 views.

The views are pretty complex, with custom background and bitmaps on top of it, so I end up with lots of views in memory that I will probably never use.

My question is twofold:

  1. Should I even worry about it? right now I am not in the point where I get OOM exceptions, but will I ever get there or is ListView smart enough to "let go" of some of those views when resources get tight?

  2. If I do need to worry about it, is there a way to explicitly tell ListView to clear up it's recycler, or even disable it somehow?

A possible solution is to use the same XML for both layouts, have two ViewGroups in there and just set the visibility of one of them to GONE, but it seems like a waste to have a fairly complex view hierarchy if I am never going to show it.

Bob
  • 2,586
  • 7
  • 20
  • 33

3 Answers3

1

One suggestion to deal with two different type of child view in Adapter is using getViewTypeCount method and let the adapter know actually you use two different type of view.

The listView maintains each recycler per each view type (in your case, the number will be 2), so you don't worry to any OOM exceptions and don't need to tell ListView to clear up it's recycler.

For more detailed description, Check: getViewTypeCount and getItemViewType methods of ArrayAdapter

Code snippet for implementation:

public class SampleAdapter extends ArrayAdapter<String> {

    ...

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

    @Override
    public int getItemViewType(int position) {
        //the result must be in the range 0 to getViewTypeCount() - 1.
        if( position < 10 )
            return 0;
        else
            return 1;
    }

    @Override
    public View getView(int position, View convertView, ViewGroup parent) {
        switch( getItemViewType(position) ){
            case 0:
                //do something for type1 view.
                break;
            case 1:
                //do something for type2 view.
                break;
        }
        return convertView;
    }
}
Community
  • 1
  • 1
Chansuk
  • 792
  • 4
  • 7
  • I am already using getViewTypeCount() and getItemViewType(). The thing is that when I scroll through the second half of the list, some of the type 1 views are still held in the recycler. – Bob Sep 16 '13 at 23:45
1

Should I even worry about it?

No, as the user is perfectly capable of scrolling up, thereby returning to type 1 rows.

right now I am not in the point where I get OOM exceptions, but will I ever get there or is ListView smart enough to "let go" of some of those views when resources get tight?

Once you start getting OutOfMemoryError messages, this ListView will not be your problem. You only have so many row View structures, and all should be really cheap from a memory consumption standpoint.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
0

I would not worry too much when having only 2 view types.

If you want to optimize it, I suggest not having a very complex layouts and instead use custom View and do drawing of the Bitmaps yourself. A bit more complex task, but will bring better UX when going through midpoint.

MaciejGórski
  • 22,187
  • 7
  • 70
  • 94