Fixed
Status Update
No update yet.
Comments
kl...@google.com
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
https://android-review.googlesource.com/1123258
https://goto.google.com/android-sha1/b90079595f33f58fece04026a97faa0d243acdb1
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
na...@google.com
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
https://android-review.googlesource.com/1288456
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
na...@google.com
This bug was linked in a change in the following release(s):
androidx.compose.foundation:foundation:1.3.0-rc01androidx.compose.ui:ui:1.3.0-rc01
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 7e77bb541331ce0d62cabad732e43eca41ac978a
Author: Zach Klippenstein <klippenstein@google.com>
Date: Wed Jul 06 11:42:21 2022
Move BringIntoView queueing into the scrollable implementation.
This change removes the over-complicated coroutine-based queuing of
bringIntoView requests in the BringIntoViewResponder, which now is only
responsible for dispatching the request to the actual responder
interface and propagating it up the modifier local chain.
This gives the actual responder implementation (i.e. in
Modifier.scrollable) all the information about conflicting
requests and manage the queue of ongoing requests with an actual,
explicit queue that is much more straightforward than the previous
coroutine job chaining mess. Each request is stored in an actual list
along with the continuation from the request, and requests are
explicitly resumed or cancelled when needed. This also makes debugging
easier, because there's an actual queue data structure we can inspect,
which contains all the actual information about each request.
It also completely changes how the scroll animation is performed.
On every frame, the scroll target is recomputed to account for
changes in the viewport size, the request size, or the set of active
requests since the last frame, while still keeping the animation
smooth. The animation logic is in its own class, which allows a single
suspend animation call to animate to a target value that can be updated
while the animation is running.
While this change is a valuable cleanup on its own, it also fixes
focused child tracking with an explicit API for keeping a thing in view.
Fixes:
Bug:
Bug:
Bug:
Bug:
Test: ScrollableFocusableInteractionTest
Test: androidx.compose.foundation.relocation.*
Test: RebasableAnimationStateTest
Test: BringIntoViewRequestPriorityQueueTest
Relnote: "Rewrote the way scrollables respond to
`bringIntoViewRequesters` and focusables to better model the
complexity of those operations and handle more edge cases."
Change-Id: I2e5fec8c8582a8fe1f191e37fd0f4f9165678664
M compose/foundation/foundation/api/current.txt
M compose/foundation/foundation/api/public_plus_experimental_current.txt
M compose/foundation/foundation/api/restricted_current.txt
M compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/FoundationDemos.kt
M compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/ScrollableFocusedChildDemo.kt
A compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/relocation/BringIntoViewResponderDemo.kt
M compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/relocation/BringRectangleIntoViewDemo.kt
M compose/foundation/foundation/samples/src/main/java/androidx/compose/foundation/samples/BringIntoViewSamples.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/ScrollableFocusableInteractionTest.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/lazy/list/LazyListFocusMoveTest.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/relocation/BringIntoViewResponderTest.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/relocation/BringIntoViewScrollableInteractionTest.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/BringIntoViewRequestPriorityQueue.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/ContentInViewModifier.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/UpdatableAnimationState.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/relocation/BringIntoViewResponder.kt
A compose/foundation/foundation/src/test/kotlin/androidx/compose/foundation/gestures/BringIntoViewRequestPriorityQueueTest.kt
A compose/foundation/foundation/src/test/kotlin/androidx/compose/foundation/gestures/UpdatableAnimationStateTest.kt
https://android-review.googlesource.com/2178020
Branch: androidx-main
commit 7e77bb541331ce0d62cabad732e43eca41ac978a
Author: Zach Klippenstein <klippenstein@google.com>
Date: Wed Jul 06 11:42:21 2022
Move BringIntoView queueing into the scrollable implementation.
This change removes the over-complicated coroutine-based queuing of
bringIntoView requests in the BringIntoViewResponder, which now is only
responsible for dispatching the request to the actual responder
interface and propagating it up the modifier local chain.
This gives the actual responder implementation (i.e. in
Modifier.scrollable) all the information about conflicting
requests and manage the queue of ongoing requests with an actual,
explicit queue that is much more straightforward than the previous
coroutine job chaining mess. Each request is stored in an actual list
along with the continuation from the request, and requests are
explicitly resumed or cancelled when needed. This also makes debugging
easier, because there's an actual queue data structure we can inspect,
which contains all the actual information about each request.
It also completely changes how the scroll animation is performed.
On every frame, the scroll target is recomputed to account for
changes in the viewport size, the request size, or the set of active
requests since the last frame, while still keeping the animation
smooth. The animation logic is in its own class, which allows a single
suspend animation call to animate to a target value that can be updated
while the animation is running.
While this change is a valuable cleanup on its own, it also fixes
focused child tracking with an explicit API for keeping a thing in view.
Fixes:
Bug:
Bug:
Bug:
Bug:
Test: ScrollableFocusableInteractionTest
Test: androidx.compose.foundation.relocation.*
Test: RebasableAnimationStateTest
Test: BringIntoViewRequestPriorityQueueTest
Relnote: "Rewrote the way scrollables respond to
`bringIntoViewRequesters` and focusables to better model the
complexity of those operations and handle more edge cases."
Change-Id: I2e5fec8c8582a8fe1f191e37fd0f4f9165678664
M compose/foundation/foundation/api/current.txt
M compose/foundation/foundation/api/public_plus_experimental_current.txt
M compose/foundation/foundation/api/restricted_current.txt
M compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/FoundationDemos.kt
M compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/ScrollableFocusedChildDemo.kt
A compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/relocation/BringIntoViewResponderDemo.kt
M compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/relocation/BringRectangleIntoViewDemo.kt
M compose/foundation/foundation/samples/src/main/java/androidx/compose/foundation/samples/BringIntoViewSamples.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/ScrollableFocusableInteractionTest.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/lazy/list/LazyListFocusMoveTest.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/relocation/BringIntoViewResponderTest.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/relocation/BringIntoViewScrollableInteractionTest.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/BringIntoViewRequestPriorityQueue.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/ContentInViewModifier.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/UpdatableAnimationState.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/relocation/BringIntoViewResponder.kt
A compose/foundation/foundation/src/test/kotlin/androidx/compose/foundation/gestures/BringIntoViewRequestPriorityQueueTest.kt
A compose/foundation/foundation/src/test/kotlin/androidx/compose/foundation/gestures/UpdatableAnimationStateTest.kt
na...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.foundation:foundation:1.4.0-alpha04
Description
If the node making the request shrinks during the animation, it will be scrolled too far. If it grows, it won't be scrolled far enough. It also uses the wrong coordinates if the position of the node changes for some reason other than the BIV animation itself.