Fixed
Status Update
Comments
th...@google.com <th...@google.com> #2
@klippenstein
kl...@google.com <kl...@google.com>
ap...@google.com <ap...@google.com> #3
Project: platform/frameworks/support
Branch: androidx-main
commit 9e3c7fe79369a1f772438339bf86958eb99ee4f2
Author: Zach Klippenstein <klippenstein@google.com>
Date: Thu Jul 13 09:43:02 2023
Defer AndroidView update callback until view is attached.
The snapshot observer is only started when the view is attached, so if
we run the update callback before that, none of the state reads will be
observed.
This bug is not triggered in a test if the state is set by the test –
it's only triggered if the state is updated by an effect. Added a test
that does that and fails before this fix.
This is also technically more efficient, since it avoids running the
update callback if the view never becomes attached. I think it also
means we can use the Owner's SnapshotStateObserver instead of creating
our own, although I haven't made that change in this CL.
Fixes: b/291094055
Test: AndroidViewTest.androidView_updateObservesStateChanges_fromEffect
Relnote: "`AndroidView`'s `update` callback's first invocation will now
be defered until the view is attached, instead of running when the
composition that introduces the `AndroidView` is applied. This fixes
a bug where the `update` callback wouldn't be invalidated if a state
it read was changed immediately by an effect."
Change-Id: Ie94381c17c417b4161d1531c9731a3b077ad46fb
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/viewinterop/AndroidViewTest.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/viewinterop/AndroidViewHolder.android.kt
https://android-review.googlesource.com/2657055
Branch: androidx-main
commit 9e3c7fe79369a1f772438339bf86958eb99ee4f2
Author: Zach Klippenstein <klippenstein@google.com>
Date: Thu Jul 13 09:43:02 2023
Defer AndroidView update callback until view is attached.
The snapshot observer is only started when the view is attached, so if
we run the update callback before that, none of the state reads will be
observed.
This bug is not triggered in a test if the state is set by the test –
it's only triggered if the state is updated by an effect. Added a test
that does that and fails before this fix.
This is also technically more efficient, since it avoids running the
update callback if the view never becomes attached. I think it also
means we can use the Owner's SnapshotStateObserver instead of creating
our own, although I haven't made that change in this CL.
Fixes:
Test: AndroidViewTest.androidView_updateObservesStateChanges_fromEffect
Relnote: "`AndroidView`'s `update` callback's first invocation will now
be defered until the view is attached, instead of running when the
composition that introduces the `AndroidView` is applied. This fixes
a bug where the `update` callback wouldn't be invalidated if a state
it read was changed immediately by an effect."
Change-Id: Ie94381c17c417b4161d1531c9731a3b077ad46fb
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/viewinterop/AndroidViewTest.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/viewinterop/AndroidViewHolder.android.kt
na...@google.com <na...@google.com> #4
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.ui:ui:1.6.0-alpha02
androidx.compose.ui:ui-android:1.6.0-alpha02
Description
I was unable to assert state change during unit test using espresso view matchers like so:
where SomeComposable contains an AndroidView composable that has an update block depending on a state created inside the composable.
Example of when it doesn't work in unit test -- creating the state where the composable wraps around the AndroidView()
Example of when it does work -- pushing the state delegation to another composable and having the AndroidView-wrapping Composable only accept the final string returned from state