IssueTracker

since these are in public API (:/) we need to do this in 1.2

Opening diff shortly

Project: platform/frameworks/support
Branch: androidx-master-dev

commit d576cbdc911cba16638a44fd8223391a90a07ef7
Author: Mike Nakhimovich <digitalbuddha@users.noreply.github.com>
Date:   Tue Aug 11 09:30:34 2020

    [GH] Hide deprecated internal API.
   
    ## Proposed Changes
   
    * `RoomDatabase.java` has protected `mCallbacks` field which is leaking in the API docs, we should @Hide it.
   
    ## Testing
   
    Test: Ran unit tests locally
   
    ## Issues Fixed
   
    Fixes: 76109329
   
    This is an imported pull request from https://github.com/androidx/androidx/pull/61.
   
    Resolves #61
    Github-Pr-Head-Sha: 6440daa3a63752c7f9d5ba2a390248cd85bc634f
    GitOrigin-RevId: fe92d8466a59b44b218b6ca3cbd57dcda17992f7
   
    Change-Id: Id599cdf5b02b32bdae0166266fb7da967598fe92

A       room/runtime/api/current.ignore
M       room/runtime/api/current.txt
M       room/runtime/api/public_plus_experimental_current.txt
M       room/runtime/api/restricted_current.txt
M       room/runtime/src/main/java/androidx/room/RoomDatabase.java

https://android-review.googlesource.com/1396827

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.