Hey there, I have a large amount of items grouped ...
# compose
s
Hey there, I have a large amount of items grouped into several groups. Conceptually it looks like Image-1. So a couple of Material Cards with a large number of items inside each. Since the time-to-draw is actually pretty bad, I want to use a LazyColumn to improve performance. However, since the elements are grouped into cards it's not easy to pack them into a LazyColumn. I can't make every Card into an individual LC because that would mean having several scrollable composables with undefined height in a row. The only idea I have is to "fake" the visual presentation of the Cards by rendering certain backgrounds for each item inside the LazyColumn. See Image-2 how that might look like. But that's very inconvenient because the actual UI is pretty complicated already. Are there any nice approaches for dealing with nested structures in a LC?
c
how many items in each card? You could probably just use one LazyColumn with each card as an item. Alternatively, perhaps ditch card and use heading or divider for your category grouping. Something that doesn't need to be drawn around the end of the list. That way you could use a forEach with item{} and items(list) {item -> ...} blocks for the header and children respectively
c
You could also consider introducing an intermediate data structure that matches your UI better, to pass to
items
in LazyColumn as a list of chunks of three or a list of Triples (basing # off your screenshot). That way each item is a Card with three sub-items.
s
@Christopher Mederos It's a dynamic number. But my estimation is that I'll probably have two cards, the first one having up to ~30 items, the second one up to ~100. So splitting the LC into just two items isn't going to cut it. I can't ditch the cards because of agreed-upon designs. Or rather, I can't ditch the visuals. Faking the card visuals is a possibility. @Chris Sinco [G] Sorry, the example screen might have been misleading there. Each card will have way more than 3 items; there isn't an exact number.