Why would a

SaveableStateHolder

fail to save/restore the state of a

LazyList

? Ive verified that my keys are correct, and Ive stripped out any surrounding logic, yet it doesnt do its thing.

It usually do not fails it's just that it restore too early, they added some hacks when there's 0 items to wait but there's many cases where's it not enough and you need to ensure nothing is displayed in the list until all is ready to be restored.

Thanks for the idea @Tolriq. I found out that it was a bug in compose 1.2.0-alpha02. Downgrading didnt help, so I thought it was something different.. Turns out accompanist was pulling in alpha02 even though I wasnt explicity targeting it! mind blown

I use 1.2 A2 and have no issues with it. Log your state to see what happens.

Thats strange. Looking at the LazyListState, a new instance is created in both cases, but with alpha01 the scroll-position/etc is restored as well. Just seeing the default values everytime with alpha02. Good thing I didnt spend 2 entire days looking into this 🥲

Are you logging the state position on each composition? I'm pretty sure you'll see it with the proper values, then a recompose with some items will set them to 0.

I think our scenarios are different, my items are cached between the recompositions; so even if I leave the screen and come back later, it will start with the last set of items.

Paging3 ? 🙂

Im just using a plain list! The items are available on the first composition as well, my architecture is a little different but its akin to using

StateFlow

where theres always an initial value available.

Then don't log, but your issue on the tracker have no repro, no code and nothing that anyone will be able to handle, so not sure what you expect here. Specially when it works for others and they have regressions tests on it. Anyway I'm out good luck.

True, but considering that the exact same code works in alpha01, hopefully the diff between the two can provide enough information to nail down the problem!

So you give 0 information on your issue, all the tests pass and you expect Google to find a random issue without a repro or any useful detail for them.

Well I think thats better than nothing. Clearly its not working in a basic case like mine.

Don’t worry, we already fixed it as part of https://issuetracker.google.com/issues/217210970. Turned out the content is not being correctly saved when it is located in components using SubcomposeLayout internally, in this example Scaffold

@Andrey Kulikov I just saw! Thank you so much ❤️