IssueTracker

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

  The following changes were cherrypicked through Coastguard (https://android-build.googleplex.com/coastguard/)
  Release Track: (https://android-build.googleplex.com/coastguard/dashboard/6093116828680192/#/cherrypickHistory/all)
  Created: 2019-10-14 17:23:42.610596+00:00
  Changes: aosp/1123258
 

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

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.

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.

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?

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?