Status Update
Comments
se...@google.com <se...@google.com>
si...@google.com <si...@google.com> #2
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
so...@google.com <so...@google.com> #3
si...@google.com <si...@google.com> #4
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
si...@google.com <si...@google.com> #5
might be a P3 as well. I wanted to remove P4 since this is in our current list of tasks to do.
ni...@google.com <ni...@google.com> #6
Bulk edit: This bug is currently marked as blocking Compose 1.0. Once rc01 is cut, all changes will need to go through our cherry-pick process.
If you intend to fix it in Compose 1.0, no action is needed except prioritizing finishing this work.
Otherwise, please remove this bug from the appropriate 1.0 hotlist (likely
Thanks!
so...@google.com <so...@google.com> #7
Played a bit with one of the ideas: if the line being edited is not the last one, leave current behavior (i.e. show the cursor); otherwise use the decoration box bounds. In that case single line text field will always display padding/decoration box. In multi-line text field (Notes like app for example) we won't show the decoration box if not the last line is being edited.
Alternatively, I want to consider another option where we show the cursor and a bit more. I'll add more details when I played more with the idea.
We might need a UX input here.
Another point is that we need to make sure we request rectangle after editing, as currently we only do this on initial focus. As a result, when user types, the cursor becomes hidden behind the keyboard anyway.
so...@google.com <so...@google.com> #8
Zach, this one is fixed, isn't it? Probably can be marked as duplicate
kl...@google.com <kl...@google.com> #9
This isn't working yet because of bringIntoView
call it works as expected.
ap...@google.com <ap...@google.com> #10
Branch: androidx-main
commit 04501ae82a6f8349c5a4037080bb2b93c7fddefe
Author: Zach Klippenstein <klippenstein@google.com>
Date: Fri Apr 15 15:26:57 2022
Ignore bringIntoView requests that are already satisfied by an in-progress request.
If a new bringIntoView call happens before the previous one is finished,
then if the new one requests a rectangle that will already be in
view after the old request is satisfied, the new request is ignored.
Bug:
Fixes:
Test: New tests for BringIntoViewResponder and text field.
Test: ./gradlew :compose:f:f:cDAT
Relnote: "Concurrent `BringIntoViewRequester.bringIntoView` calls for
rectangles that are completely overlapping will now only honor the
larger rectangle's request."
Change-Id: I34be70f23527e4fea694fd5266bbc127cc1d1b0b
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/textfield/TextFieldFocusTest.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/relocation/BringIntoViewRequester.kt
M compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/text/TextFieldsInScrollableDemo.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
Description
If the software keyboard comes into view, decorationBox of BasicTextField gets ignored. The keyboard appears --> the content scrolls up, but only until the TextFields input area. It does not observe the extra padding provided by the decorationBox.