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

Sorry, the arch components got a bit stuck in our release process. Shipping in the next couple of days, hopefully tomorrow.

No worries, sounds good! Thanks for the awesome work!

Fix is in Paging Alpha5, just released: https://developer.android.com/topic/libraries/architecture/release-notes.html#december_11_2017

Works great, thanks a ton!

I have a problem that I believe is related to this.

Scenario 1:
When I load empty item, onZeroItemLoaded is called once. At that momen user have no data and all is well. But after t minutes the data for users are populated. At this point I try to scroll the Recyclerview and onZeroItemLoaded is never called again. AFAIK, it was supposed to be called. If am wrong can someone correct me?

Scenario 2: User logs into application and there are few items in the server (less than page size set in live page builder). onZeroItemLoaded is called and inserts data in room database, happy time! Then trying to scroll recylerview onItemEndLoaded is not being called. If I close app and start it again, this time onItemEndLoaded get called twice and it never get called again.

I have read all I can on the internet for days and could not find something that either shows of what am doing wrong or missing. So I concluded this might be a bug

for S1: There is on indication that we can know if data is ready on the server so we cannot call onZeroItems loaded. Attempt the scroll RV won't trigger aynthing since it won't scroll.
for S2: same as above. When the list is loaded the first time, it triggers end load events since we've reched end of  the list and laid it out. but after that, no scroll will happen and we don't know your server has more data.

Both of these problems boils down to the fact that your source (server) has more data but you don't know about it. You need to implement it yourself, and if you ever update the database, paging will automatically refresh.

I think I misunderstood how the paging library works in such scenario. Can you help me understand when does paging kick in in let say scenario2? Is it only when items are more than page size defined in config?

I agree that I should write logic to check on the server. I had false assumption that trying to scroll triggers everything. I was wrong! I would appreciate your help on this question. I just don't want to reinvent the whole thing that paging already does!

for sceneario 2, you really need a custom solution depending on your backend. There is no way paging can know the data on your server changed besides the invalidate() in the DataSource.
usually, these things are implemented as pull to refresh where user triggers a refresh and then you go and fetch new data.

Alternatively, your backend could be sending a push notification when data changes. It is usually unnecessary / overkill but depends on your use case.

Some apps handle this by having a persistent connection to their server to get these notifications and only keep that connection when app is in the foreground. Again, you need to implement it since it heavily relies on your backend.

Thank you for the comment. I went with refresh path and it's OK.