Without measuring each item how would a list with items that vary in height have a smooth scroll bar? It seems that if setSmoothScrollBar is set to false then the scrollbar indicator/thumb jumps from item to item, if set to true then the scrollbar indicator changes size to match each item. Neither is an expected behavior from a scrollbar. What is the best way to accomplish this? It seems less than ideal to measure each item.
I see that AbsListView <http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/5.1.1_r1/android/widget/TextView.java#TextView.computeVerticalScrollRange%28%29> uses the list size * 100 for the scrollRange and then does some calculations for each item for the scrollExtent but this doesn't appear to work well with a recyclerView, the numbers don't seem to ever quite work and I'm not sure why 100 is being used. On Sunday, October 7, 2012 at 4:37:18 AM UTC-4, Romain Guy wrote: > > ListView sometimes uses the "item" unit (total number of items, first > visible item, etc) instead of pixels because it cannot always know the > exact pixel height of all items. You can also use units that come from your > dataset (a map could very well use meters for instance, a graph could use > time or percentage.) > > Feel free to use pixels but it's not mandatory. What matters is that all 3 > methods use the same unit. > On Oct 6, 2012 7:50 AM, "Raffaele Sgarro" <[email protected] > <javascript:>> wrote: > >> The documentation for computeVerticalScrollRange() says >> <http://developer.android.com/reference/android/view/View.html#computeVerticalScrollRange()> >> : >> >>> >>> Compute the vertical range that the vertical scrollbar represents. >>> The range is expressed in *arbitrary units* that must be the same as >>> the units used by computeVerticalScrollExtent() >>> <http://developer.android.com/reference/android/view/View.html#computeVerticalScrollExtent()> >>> andcomputeVerticalScrollOffset() >>> <http://developer.android.com/reference/android/view/View.html#computeVerticalScrollOffset()> >>> . >> >> >> The same *arbitrary units* are mentioned in the other two methods. >> Looking at the sources, this is what I found: >> >> protected int computeVerticalScrollRange() { >> return getHeight(); >> } >> protected int computeVerticalScrollOffset() { >> return mScrollY; >> } >> protected int computeVerticalScrollExtent() { >> return getHeight(); >> } >> >> So, what's going on here? getHeight() is documented to return the height >> of the view in pixels, and I wander if it makes any sense to measure things >> in miles, kilometers, astronomic units... Do they documented it in such a >> way to allow subclasses to use percentages or number of items? >> >> In particular, I looked at this methods because I'm implementing a >> ListView with a custom background >> <http://stackoverflow.com/q/12737600/315306>, and it seems I need to >> deal with scroll dimensions >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Android Developers" group. >> To post to this group, send email to [email protected] >> <javascript:> >> To unsubscribe from this group, send email to >> [email protected] <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/android-developers?hl=en > > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/557272a4-c089-4d57-8e71-d6aaa75dcd01%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
