Fixed
Status Update
No update yet.
Comments
ma...@google.com
kl...@google.com
kl...@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
kl...@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
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit c1cf16ad7e547a8e267fd25fb6698ecbbb0ca58a
Author: Zach Klippenstein <klippenstein@google.com>
Date: Wed Apr 20 14:36:22 2022
Improve BringIntoViewResponder dispatching behavior for concurrent requests.
The initial fix for this, aosp/2065910, did not ensure that
BringIntoViewRequester.bringIntoView didn't return until the request was
satisfied or interrupted, and couldn't queue requests.
This change queues all overlapping requests, ensures bringIntoView
doesn't return until the previous request is cancelled or complete, and
adds a bunch of tests for various overlapping and interrupting
behaviors. It also improves the documentation a bit.
Fixes:
Test: New tests in BringIntoViewResponderTest
Test: ./gradlew :compose:f:f:cDAT
Relnote: "`BringIntoViewRequester.bringIntoView` will now always suspend
until the request is either completed or was interrupted by a newer,
non-overlapping request. Overlapping requests will be queued."
Change-Id: I43e7f73af86615f08e2d2d05bfd05ac96d0c65e4
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/relocation/BringIntoViewRequester.kt
M compose/foundation/foundation/src/androidMain/kotlin/androidx/compose/foundation/relocation/BringIntoViewResponder.android.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/relocation/BringIntoViewResponderTest.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/relocation/BringIntoViewResponder.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/relocation/BringIntoView.kt
https://android-review.googlesource.com/2071910
Branch: androidx-main
commit c1cf16ad7e547a8e267fd25fb6698ecbbb0ca58a
Author: Zach Klippenstein <klippenstein@google.com>
Date: Wed Apr 20 14:36:22 2022
Improve BringIntoViewResponder dispatching behavior for concurrent requests.
The initial fix for this, aosp/2065910, did not ensure that
BringIntoViewRequester.bringIntoView didn't return until the request was
satisfied or interrupted, and couldn't queue requests.
This change queues all overlapping requests, ensures bringIntoView
doesn't return until the previous request is cancelled or complete, and
adds a bunch of tests for various overlapping and interrupting
behaviors. It also improves the documentation a bit.
Fixes:
Test: New tests in BringIntoViewResponderTest
Test: ./gradlew :compose:f:f:cDAT
Relnote: "`BringIntoViewRequester.bringIntoView` will now always suspend
until the request is either completed or was interrupted by a newer,
non-overlapping request. Overlapping requests will be queued."
Change-Id: I43e7f73af86615f08e2d2d05bfd05ac96d0c65e4
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/relocation/BringIntoViewRequester.kt
M compose/foundation/foundation/src/androidMain/kotlin/androidx/compose/foundation/relocation/BringIntoViewResponder.android.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/relocation/BringIntoViewResponderTest.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/relocation/BringIntoViewResponder.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/relocation/BringIntoView.kt
Description
If two requests are made concurrently on the same BringIntoViewRequester, if the responder is using standard animation APIs (like scrollable is) then the last request to be processed will cancel all the animations for the other requests.
This currently happens when text fields gain focus. Consider a text field with a large decoration box (eg a material text field). The focusable first gets the focus event and makes a request to bring the entire decoration box into view. Then the text field gets the focus event and makes a request to bring the cursor area into view. The cursor area is always inside the decoration box. If the cursor area is already in view, that second request noops and the first request completes, bringing the entire decoration box into view. However, if the cursor area started off hidden (as is common, eg if the entire text field would be covered by the newly shown keyboard), then the second request cancels the first and only the cursor area is brought into view, which means part of the decoration box will stay clipped.
I think the solution is that the bring into view responder should detect when a request comes in while a previous request is still being processed, somehow calculate the merge of the two requests, and only cancel the animation if it needs to adjust it to handle the merge result.
The merge algorithm might look something like this:
In particular, in the case where the entire text field can fit in the responder, this algorithm would always prioritize requests for bringing the entire text field into view over requests to bring the cursor into view.
This logic must happen at each responder node. Because text fields contain their own scrollable below the focusable, even if the cursor request will be ignore by a scrollable much higher up in the tree, the text field's own scrollable still needs to process it.