Fixed
Status Update
Comments
rv...@google.com <rv...@google.com>
p....@gmail.com <p....@gmail.com> #2
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
rv...@google.com <rv...@google.com> #3
p....@gmail.com <p....@gmail.com> #4
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 ( b/140759491 ).
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
rv...@google.com <rv...@google.com> #5
That is the default behaviour. Could you clarify with an image or video what your desired behaviour is?
p....@gmail.com <p....@gmail.com> #6
PFA. I want behaviour like this. If focus is not last visible item of row then it should not get scrolled automatically.
rv...@google.com <rv...@google.com> #7
Okay. And what if there are more items to the right and the user clicks DPAD_RIGHT in the above image? Where do you expect the focus to go? And how should it look like?
p....@gmail.com <p....@gmail.com> #8
In that case I will scroll row by some offset but I want to control it same as Google Live.
rv...@google.com <rv...@google.com> #9
This looks like a custom implementation of PositionFocusedItemInLazyLayout. You can use that as a starter and update the math logic in the function based on your needs.
p....@gmail.com <p....@gmail.com> #10
yes, I am sending flag and handling it and it's working fine. Thanks for you quick help.
[Deleted User] <[Deleted User]> #11
Is there a way to have this done on the focused item's parent composable? I'm running into an issue with a Carousel that has focusable buttons. It is scrolling to the first focused button. This worked with the pivot offsets in the TV API but not this new one.
rv...@google.com <rv...@google.com> #12
It is not clear what the issue is. Can you please file a new issue with a minimal reproducible snippet of code along with the library versions?
[Deleted User] <[Deleted User]> #13
Will do, I noticed it only happens on the initial composition. If I scroll the issue fixes itself. I'll follow up when I have more details.
Description
Starting from version
1.0.0-alpha11
ofandroidx.tv.foundation
, tv lazy layouts are deprecated and will be removed in the future releases. This includes the following components and their respective tv-foundation dependencies.TvLazyRow
TvLazyColumn
TvLazyHorizontalGrid
TvLazyVerticalGrid
This deprecation follows a new feature addition in the compose foundation's lazy layouts. The tv lazy layouts offered a Feature CL
pivotOffsets
functionality that would allow to position the current focused item at a specific position. This can now be achieved by providing a custom BringIntoViewSpec to the compose foundation's lazy layouts.The following part of the ticket will talk about migration from tv lazy layouts to compose foundation layouts.
Prerequisites
1.7.0-beta02
or above.androidx.compose.foundation
androidx.compose.runtime
androidx.tv.foundation
dependency from your package if you were only using the tv lazy layouts.Option 1. If you are using tv lazy layouts WITHOUT customizing the
pivotOffsets
.Changes
androidx.compose.foundation
Tv
prefix from all theTvLazy*
components.Before: Using
androidx.tv.foundation
After: Using
androidx.compose.foundation
Option 2. If you are customizing the
pivotOffsets
in the tv lazy layouts.Changes
androidx.compose.foundation
Tv
prefix from all theTvLazy*
components.Custom BringIntoView spec:
Now that we have the custom BringIntoView spec, usage it pretty straightforward. Wrap the entire app with
PositionFocusedItemInLazyLayout
and all your inner lazy layouts will respect that.You can even override it for specific layouts like shown below: