How to apply latest Paging loading mechanism with GithubBrowserSample?

GithubBrowserSample combine with network and database, which should use BoundaryCallback when migrating to new Paging loading mechanism, and it only feed the last item when reaching end, but github API only use page number when querying next page. How do I use last item to query next github page?

[ChrisCraik]

To me, the primary dirtiness of persisting the page key is in resuming a paged network query after process death, potentially after a long period of time. If you’re comfortable with resuming that query though, storing it in the DB or similar is quite reasonable.

Paging only ever call the BoundaryCallback.onItemAtEndLoaded if the last page is fully loaded, so that’s always true (and I can clarify that in docs as well)

The reason we don’t pass anything else is that we don’t want to pass information that looks safe, but sometimes isn’t, e.g.:

• We don’t pass you page count, since the page size loaded from the DataSource is often different from network page size. E.g. 10 pages of 50 items loaded from the network, but that’s just 5 pages of 100 items from DB, page count isn’t useful. You can try and make them the same, but you can hit cases where (especially network) paged APIs silently coerce your page size to some maximum value.

• We don’t pass number of items loaded, because we may not have loaded all data from position 0, or we may have dropped pages due to a DB side change, which makes us requery the DB.

[ChrisCraik]

There are a few different options for how to use a BoundaryCallback:

1. Api uses key from within item, just use item passed to BoundaryCallback. This is what we do in the samples, and it’s the easiest approach if your network api allows it.

2. Api uses page key/page index. The Paging library doesn’t know about the page key or page index from the BoundaryCallback, so you need to track it yourself. It’s not stored in the query that the Paging library is loading from, but there are two ways to handle it:

2a) Store the key in memory, inside your BoundaryCallback, and trigger a refresh when you start paging. Often it doesn’t make sense to keep querying page after page from network if your process has died, and is restarted many hours or days later. The Paging codelab stores it in memory: https://codelabs.developers.google.com/codelabs/android-paging/index.html#8 though it doesn’t implement the refresh on launch.

2b) Store the key in local storage, so you can resume your query if the process dies, or if you restart your paging stream from local storage. With a positional / page index api, there’s a simple way to do this: e.g. githubService.loadPage(listSize / NETWORK_PAGE_SIZE).

Paging doesn’t pass currentListSize to the boundaryCallback, though. That’s because the library doesn’t necessarily know the number of items in local storage (since you can disable placeholders, or a DataSource can choose not to count the number of items). In practice, you can just do:

runOnDbThread {
    int listSize = countItems()
    runOnNetworkThread {
        githubService.loadPage(listSize / NETWORK_PAGE_SIZE);
    }
}

If you’re using page keys though, and want to resume a paged query without refreshing, the only option is to store the current page key.

Let me know if this makes sense, and I’ll add this explanation to the docs.