QuickReturnListView icon indicating copy to clipboard operation
QuickReturnListView copied to clipboard

List unscrollable with custom Adapter

Open egfconnor opened this issue 12 years ago • 6 comments
trafficstars

I've tried using your code but it severely lags when using a custom adapter. Looping through every view in computeScrollY() and inflating tons of views seems terribly inefficient and I have no clue how this code could work.

Am I missing something or have you tested this on any other adapter?

egfconnor avatar Aug 28 '13 18:08 egfconnor

Setting a boolean so it runs once has fixed it, but I'm not sure what the side effects are:

listView.getViewTreeObserver().addOnGlobalLayoutListener( new ViewTreeObserver.OnGlobalLayoutListener() { boolean haveRan = false;

                        @Override
                        public void onGlobalLayout() {
                            if (haveRan == false) {
                                mQuickReturnHeight = quickReturnLayout
                                        .getHeight();
                                listView.computeScrollY();
                                haveRan = true;
                            }
                        }
                    });

egfconnor avatar Aug 28 '13 18:08 egfconnor

@egfconnor I think the issue relates to the fixed adapter size shown in the example. If you change the dataset (grow or shrink) in the adapter and then call notifyDataSetChanged on the adapter, an IndexOutOfBoundsException is thrown.

This is caused by the way @LarsWerkman defined the mItemOffsetY array in the computeScrollY function. As currently defined, the mItemOffestY array is defined ONLY once and the size is based on the initial size of the dataset.

To fix it so that it can accept changes in the dataset, change this line:

if (mItemOffsetY == null)

to

if (mItemOffsetY == null || mItemOffsetY.length != mItemCount)

That will allow the mItemOffsetY array to be redefined when the dataset changes and should allow it to work with custom adapters (especially cursoradapters and loaders).

bkhall avatar Sep 19 '13 15:09 bkhall

Thanks for the info @bkhall. I will try and test this soon as currently I have went away from using it completely. Will hopefully create a sample that isolates everything to a simple level.

egfconnor avatar Sep 19 '13 16:09 egfconnor

Thanks @bkhall yeah you could do that I think!

LarsWerkman avatar Sep 24 '13 10:09 LarsWerkman

This is why I think this is not a good starting point in terms of breaking lots of conecpts crucial to ListViews and Adapters. First: it breaks when adapter's content changes. Normally this is all well designed, a call to notifyDataSetChanged from the adapter informs all observers (the list). But this approach breaks this. Second: in terms of efficiency it is a horrible mistake to call getView in a loop on ALL elements in the list. Never, ever, I repeat, never, ever, do this!

Zordid avatar Mar 27 '14 13:03 Zordid

@Zordid do you have another solution for implementation? Could you to share it?

AlexeyFreelancer avatar May 29 '14 07:05 AlexeyFreelancer