Status Update
No update yet.
Comments
to...@gmail.com
I also tried moving sharedElement to BoxWithConstraints (rather than in its content), but did not help.
So the layout hierarchy looks like this (with more details and with "..." I replaced series of "normal" layouts):
NavHost -> ... -> AnimatedVisibility -> ... -> BoxWithConstraints with sharedElement -> some content
\> ... -> AnimatedVisibility -> ... -> LazyList -> ... -> Animated Visibility -> Selection container -> BoxWithConstraints with sharedElement -> some content
Any ideas?
to...@gmail.com
In your BoxWithConstraints do you do any conditional composition? Things like:
if (constraintsExceedsCertainThreshold) composeSomeContent() else someOtherContent()
ti...@google.com
to...@gmail.com
Also note `sharedElement` is put on `BoxWithContraints` now, not on the content.
Thanks!
to...@gmail.com
Based on the stacktrace, it seems like the item in question is composed but never placed. Do you use custom precompose or prefetch logic in your lazy list?
to...@gmail.com
There is also one `AnimatedContent` above the `BoxWithConstraints`. Could this cause issues?
Thank you for looking into this.
to...@gmail.com
The AnimatedContent never skips measuring/placing children after it composes them. So I don't expect that to be the issue.
Since you mentioned the modifier is on BoxWithConstraints rather than on the children of BoxWithConstraints, my guess is it's most likely related to LazyList.
Can you clarify what type of LazyList you are using? Is it LazyColumn/Row or LazyGrid, or something else?
ti...@google.com
It's a LazyColumn.
ap...@google.com
One interesting observation is that this stack trace did not seem to come from the ComposeView with our app's Activity content. Because I did a release with copy pasted setContent + ComposeView subclass that is catching exceptions in dispatchDraw and it did not catch this crash. Is the animations framework doing content composition outside the app's composition context? One note: at the time I tried this exception catching, sharedElement was applied to the content of BoxWithConstraints (rather than to the BoxWithConstraints itself), but I don't think this would have caused the exception catching not to work.
to...@gmail.com
I'm investigating what would cause items to be composed but not placed.
We'll submit a fix in shared element in 1.8 to account for that scenario if that's an intended behavior.
Have you tried a recent 1.8 release and see if it's reproducible?
pr...@google.com
Thank you!
Unfortunately we cannot release publicly with 1.8 alpha, and we never reproed this issue locally even with 1.7.x.
Description
Jetpack Compose version: 1.8 snapshots starting with 12408595 (So included in alpha03)
I unfortunately have some trouble to build a small repro but that commit broke transitions handled by
AnimatedContentin my app.See attached video.
There's also some details in slack in a thread with Doris.
To resume, there's some size resolution issues when removing and adding back screens that makes the
AnimatedContentwrongly detect a size change and doing wrong size animations.You can see in the video that the fade transition does work, then when switching screen then going back it no more work correctly and animate the size for no reasons.
Forcing
.using(null)does workaround the issue.When reaching the broken state, if both contents of
AnimatedContentare boxes with.fillMaxSize()then it just shows a black screen as is it was animating from 0 to 0 size. If one of the content does not have the.fillMaxSize()then it leads to the size animations you can see in the video.