Fixed
Status Update
Comments
ap...@google.com <ap...@google.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
ap...@google.com <ap...@google.com> #3
il...@google.com <il...@google.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
ir...@gmail.com <ir...@gmail.com> #5
Hi,
I'm trying to implement the AbstractListDetailFragment. On a mobile device it works as expected, the detail pane is closed until I select one of the items of the list pane, and the onClickListener calls to slidingPaneLayout.open() and then the detail pane gets opened. But, when I run the app on a tablet, expecting both panels to be displayed at the same time since the screen is large enough for that to happen, I see that it works just as in the mobile device, it is necessary to call to slidingPaneLayout.open() in order to see the detail pane, and it is displayed in front of the list pane, while both panes should be displayed one besides the other.
Is this the intended behavior? if so, is there a way to indicate that both panes should be displayed when the space available is larger than the sum of the panes' width?
Thank you in advance.
I'm trying to implement the AbstractListDetailFragment. On a mobile device it works as expected, the detail pane is closed until I select one of the items of the list pane, and the onClickListener calls to slidingPaneLayout.open() and then the detail pane gets opened. But, when I run the app on a tablet, expecting both panels to be displayed at the same time since the screen is large enough for that to happen, I see that it works just as in the mobile device, it is necessary to call to slidingPaneLayout.open() in order to see the detail pane, and it is displayed in front of the list pane, while both panes should be displayed one besides the other.
Is this the intended behavior? if so, is there a way to indicate that both panes should be displayed when the space available is larger than the sum of the panes' width?
Thank you in advance.
ir...@gmail.com <ir...@gmail.com> #6
Hi again, I fixed, hehe. The problem was I was using
ListPaneBinding.inflate(inflater)
instead of
ListPaneBinding.inflate(inflater, container, false)
when inflating the list pane.
ListPaneBinding.inflate(inflater)
instead of
ListPaneBinding.inflate(inflater, container, false)
when inflating the list pane.
te...@gmail.com <te...@gmail.com> #7
Hello, is there a way to connect the toolbar app configuration of an outer navigation graph to the inner one of the AbstractListDetailFragment? When opening the details pane while in portrait mode you don't get a back arrow in the toolbar by default. Is there a way to get the toolbar to understand to add a back arrow just for the details pane in portrait mode or do I need to create a custom solution?
te...@gmail.com <te...@gmail.com> #8
Another thought - You define the two_pane_fragment.xml in your example (https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:navigation/integration-tests/testapp/src/main/res/layout/two_pane_fragment.xml ), yet, it seems to be unused. The TwoPaneFragment class in the example does not inflate it, nor does the AbstractListDetailFragment. Actually, AbstractListDetailFragment creates a FragmentContainerView itself in its onCreateView method. However, in the guide (https://developer.android.com/develop/ui/views/layout/twopane#navigation ) you claim that this XML is needed. How should I think about this?
Description
Component used: Navigation
Version used: 2.4.0-alpha03
The Create a two pane layout guide talks through the pattern of using a
SlidingPaneLayout
that has aNavHostFragment
as its detail pane where clicking on an item in your list pane wouldnavigate()
to a new destination in the detail pane.It would be nice if this pattern was directly supported in Navigation, removing the need to manually integrate with the system back button or write the boilerplate XML layout .