Status Update
No update yet.
Comments
il...@google.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?
il...@google.com
ap...@google.com
In your BoxWithConstraints do you do any conditional composition? Things like:
if (constraintsExceedsCertainThreshold) composeSomeContent() else someOtherContent()
il...@google.com
Also note `sharedElement` is put on `BoxWithContraints` now, not on the content.
Thanks!
zv...@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?
zv...@gmail.com
There is also one `AnimatedContent` above the `BoxWithConstraints`. Could this cause issues?
Thank you for looking into this.
il...@google.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?
[Deleted User] <[Deleted User]>
It's a LazyColumn.
jb...@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.
cr...@gmail.com
Hey, sorry to insist - any more ideas here?
Description
Version used: 1.0.0-rc02
When using a Fragment such as:
<fragment>
...
<argument
android:name="myArg"
app:argType="string"
app:nullable="true"
android:defaultValue="@null"/>
</fragment>
The defaultValue="@null" causes that attribute to be dropped by the NavInflater (due to now XmlPullParser works), meaning the resulting arguments Bundle can be null as there is no way to distinguish between no default value being set and a null default value being set.
Unfortunately, even in the case where no arguments are required, Safe Args' fromBundle() and, by extension, the by navArgs(), require a non-null Bundle.
fromBundle() should only throw on a null Bundle if there are required values.