1

(I have already seen this similar question) I have a ListView for which I've written a custom adapter, and an onitemclicklistener. I'm having an issue where, when any element of the list is selected, getView is called (twice) for each of the top 4 elements of the ListView, even if those elements are not visible. This happens even if I don't call notifyDataSetChanged on the adapter - those first 4 views are fetched twice regardless. Is this normal behavior? My issue is not as much that it's being called twice for them, but that it is being called at all when updating them is not needed.

By the way, I am not using wrap_content for the height or width of the listview - the height is match_parent and the width is a fixed number of dp.

The onItemClick() method of the OnItemClickListener is here:

public void onItemClick(AdapterView<?> parent, View v, int position, long id) {

      mPicture = pictures[position];
      mPicturesAdapter.setCurrentPicture(mPicture);
      mPicturesAdapter.notifyDataSetChanged();
}

getView() from my custom Adapter (which extends BaseAdapter) is here:

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


    Log.v("tag", "Getting view for position "+position);

    LayoutInflater inflater = LayoutInflater.from(mContext);
    LinearLayout layout = (LinearLayout)
            inflater.inflate(R.layout.picture_thumbnail, parent, false);

// set up the linearlayout here ...

    return layout;
} 

On any item click, getView() is called for positions 0 - 3 twice regardless of which item was clicked.

Community
  • 1
  • 1

3 Answers3

0

Just by modifying the adapter via

mPicturesAdapter.setCurrentPicture(mPicture);

the ListView already tries to update itself. I'm guessing the onClick method will still do it's job without you calling notifyDataSetChanged

josephus
  • 8,284
  • 1
  • 37
  • 57
  • `setCurrentPicture` is a method I wrote myself. if I do not call `notifyDataSetChanged`, then getView is still called on the first 4 views twice, but **not** on the ones that are actually observable – Potluck Mittal Jul 13 '12 at 03:25
  • No, I am not. Seems worthwhile to implement though, so I will do that. However I don't believe that will affect this issue. – Potluck Mittal Jul 13 '12 at 03:29
0

Actually whatever List/Group you are using to populate the ListView, you need to first empty it and then recall it. For example, if you use ListA to populate the ListView, in the second or any consecutive update you need to empty the ListA first and then add items and then populate using it.

Ashwin Singh
  • 7,197
  • 4
  • 36
  • 55
-1
if (convertView != null){

           Then populate list

   }
TLama
  • 75,147
  • 17
  • 214
  • 392
Vishwanath.M
  • 6,235
  • 11
  • 42
  • 56
  • The issue is not with convertView - I know there is some recycling of views that I could perform in getView(), but I'm trying to understand whether it is an issue that getView is being called on unobservable views. – Potluck Mittal Jul 13 '12 at 03:27
  • @Pulak Not just you "could" perform view recycling. ListView should be used only when you NEED to recycle children. It's behavior maybe unpredictable if you do not recycle the views, causing some unknown problems. Try to recycle its children,if the problem still exists, you can still narrow down the possible causes. – reTs Jul 13 '12 at 03:35
  • @reTs - what other Views could I use for a scrollable list of 10-20 items if I didn't **need** to recycle children? – Potluck Mittal Jul 13 '12 at 03:47
  • @Pulak Simply use a ScrollView wrapping a LinearLayout, inflate all your children inside. – reTs Jul 13 '12 at 04:07
  • @Pulak Actually do you mind to tell why you are so reluctant to view recycling,though? It does no harm and you only need to add 4 or 5 lines of code in Android. – reTs Jul 13 '12 at 04:20
  • I wasn't reluctant, I simply wanted to try to understand this issue separately of view recycling. I have implemented view recycling now though. – Potluck Mittal Jul 13 '12 at 18:35