[nsmnsf]

My experience with ListView was... weird. It doesn't ask you for a height for each row like UITableView does, just for a row count. Then, it measures your views as you return them. This meant that the scrollbar was completely unreliable, it would resize based on the height of the currently visible views. Is there an obvious way around this that I'm missing? ListAdapter doesn't have anything for specifying height.

[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.

[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.

[weaksauce]

Something like this[1] didn't work for you?

[1] http://stackoverflow.com/questions/15039913/android-how-to-m...