The compose docs for "Lists and Grids" says this: ...

# compose

[Travis Griggs]

The compose docs for "Lists and Grids" says this:

If you need to display a large number of items (or a list of an unknown length), using a layout such as Column can cause performance issues, since all the items will be composed and laid out whether or not they are visible.

This seems a bit misleading to me. It focuses primarily on size, on screen rendering, optimization. But it seems that regardless of size, the real concern is if your list is dynamically sized and may be dynamically adjusted. I say this, because Modifier.animateItemPlacement is only available in lazy scopes. Even if you have 10 short items in a totally visible column, if you're going to be removing, inserting, reordering, animating those updates is a much better user experience. Is this line of reasoning missing something?

[dewildte]

I would go so far to say that because Android applications can be run on so many screen sizes and orientations it makes sense to have all lists be Lazy. <- Purely my opinion ofcourse.

[myanmarking]

No. If you have a small, fixed size list lets say up to 5/6 elements, use column/row with keys. Rendering will be faster. You get 0 benefits for using lazy variant

[Travis Griggs]

but how do you get the animations in that case?

[dewildte]

Rendering will be faster

Is that noticeable to a Human?

[myanmarking]

Yes it is. For simple composable child, sure. You almost cannot tell. With production-like cards with shadows, childs, expand and what not. Initial render takes a bit. No-Lazy is faster for few items

[myanmarking]

I dont see any point in all-one-solution lazy for everything. Few items need no lazy composable

[dewildte]

For things that are in a Lazy list already I can totally understand that. The production ready cards you mentioned being a great example.

[myanmarking]

I didnt get that

[dewildte]

Well you can not nest Lazy lists.

[Francesc]

the Lazy column/row composable are built on top of SubcomposeLayout, which is inherently more expensive because it uses the size of some children to measure other children, i.e., it requires 2 passes, so if you don't need a lazy variant, using the plain column/row will perform better

[dewildte]

I think you are all misunderstanding me.
Let’s say you have a long list of production ready cards as @myanmarking put it.
You would not render that list in a plain Column, you should put it in a LazyColumn/Grid or what ever.

[dewildte]

That’s the kind of list I meant.

[Francesc]

no, we understand you, what we are saying is that going lazy everywhere is not the best approach

[myanmarking]

I never mentioned long lists. I specifically said few items list

[Francesc]

both lazy and plain column/row have their uses, you have to pick the best tool for the task at hand

[dewildte]

I said:

…have all lists be Lazy…

I see that is of course wrong.
Please let me have the opportunity to correct it with long and non nested dynamic lists.

[dewildte]

I apologize for my error.

[Francesc]

no need to

[dewildte]

Please find it in the big hearts I know you all have with the non internet folks to forgive me 😅

[myanmarking]

Aha. I almost forgot this is not a job interview 😁

[Travis Griggs]

So to bring it back round full to the original premise. My hypothesis put forward was that if you want Columns where you want to see animated insert/remove/move (whether your count is 3 or 1000), you'll want/need to use a LazyColumn. Is that correct or not?

[Francesc]

depending on what you are after you could use AnimatedContent

[Albert Chang]

it requires 2 passes

This is not true. SubcomposeLayout is built to solve the exact case that would otherwise need two layout passes without it.