[srcreigh]

This is by design in Android. It's very computationally heavy to ask for the heights of each ListView item. Unfortunately I wasn't able to dig up my reference to this. :(

Two more things:

1. The wormy scrollbar is actually standard on Android: the messaging app does it, IIRC even the twitter app on Android does it. So even though your iOS experience tells you it's weird, any users of yours on Android likely won't notice.

2. If your items are all the same height then your scrollbar won't be wormy. So if this is really that important to you, then make your ListView return items that all have the same height.

[xsmasher]

> It's very computationally heavy to ask for the heights of each ListView item.

Can you expand on that? Do you mean that it's expensive for the OS for some reason, or do you mean that it's expensive for your (client) code to compute the height of each item?

It seems like in most cases it's a simple method like "return isHeader : HEADER_HEIGHT : ITEM_HEIGHT;"

[BitMastro]

For the OS. Imagine 999 rows containing one line of text and the last one containing a long text spanning maybe 30 lines.

To calculate the scroll accurately you need to calculate the height of 1000 elements to get the full height.

Instead in the common scenario you just calculate the height of the rows displayed on the screen and estimate the height using the average and the count.

[nsmnsf]

I don't have to imagine this, though, I've done it on iOS. It works fine, because you're rarely working with 1000 items at once. With pagination, you cache the old results, and only calculate the new 50 or so rows at a time.

[BitMastro]

On the other end, pagination is rarely used on Android, and calculating the height of a single row can be more expensive since it has to layout the children hierarchy for a row according to the screen dimensions.

[nsmnsf]

This type of layout is generally limited to social feeds, where pagination is pretty much mandatory (you have to request more results from an API). Anything entirely client-side typically uses fixed height rows.

[BitMastro]

I see your point, but this layout is used also for variable height images, variable lenght text, compound layouts, etc. The equivalent of pagination on Android is usually done using pull to refresh (horizontal swipe gestures are usually used to change topics more or less).

For something completely client side it is possible either to specify a fixed height or change the smoothScrollbar attribute of the listview (it is more expensive though and not used very much).

Nobody complains, I guess everyone is just used to the way it is. :D

[xsmasher]

Okay, sounds like you're assuming a scenario where you need to actually create the view to figure out the height, sure.

In other scenarios (contact list, list of artists and albums and songs) you know the height of an item from its type, and you can just return (one of a set of) constants like I said. That shouldn't be expensive at all.

[BitMastro]

The height is calculated automatically for the rows that are visible and you can fix it to a certain amount.

So, as screigh said, you won't have the wormy effect on contact list, artists, songs, etc. because each row is always x pixels. The same happens if you have for example a series of thin and thick rows because they average out.

Another reason why using a set of constants is not common is that we have different screen sizes and different resolutions to deal with, so what looks like a good value for a resolution might not be the best for another.