CODEWITHSUNDEEP
androidkotlinandroid-pagingandroid-paging-3
baltekg
baltekg

Reputation: 1223

Understanding PagingSource's getRefreshKey

I migrated from Paging 2 to Paging 3 library and now I use the PagingSource to load pages of data from the server. But I have trouble understanding the getRefreshKey method that has to be overriden there. I found some code samples how to implement it depending on the key used to fetch subsequent pages but I still don't get it. Based on these samples I wrote the following code:

override fun getRefreshKey(state: PagingState<Pair<String, String>, User>): Pair<String, String>? {
    return state.anchorPosition?.let { anchorPosition ->
        state.closestPageToPosition(anchorPosition)?.prevKey
    }
}

But it doesn't change a thing if I make it to always return null:

override fun getRefreshKey(state: PagingState<Pair<String, String>, User>): Pair<String, String>? = null

So is there a reason why I can't just choose the simplest solution possible? Or is there a use case that I don't see?

Upvotes: 20

Views: 9315

Answers (3)

Andrey Ovcharenko
Andrey Ovcharenko

Reputation: 1

But it doesn't change a thing if I make it to always return null:

override fun getRefreshKey(state: PagingState<Pair<String, String>, >User>): Pair<String, String>? = null

So is there a reason why I can't just choose the simplest solution possible? Or is there a use case that I don't see?

I think that null needs to be understood as Auto. If you need more control, you need to return a not-null key.

Upvotes: 0

AleksejB
AleksejB

Reputation: 332

So, this would be the difference:

Say you have your working list. A user is scrolling the list and there is some change in the list (the data was updated lets say). Then:

Case when getRefreshKey() returns null always: As your data is updated, there will be a new pair of PagingSource and PagingData, meaning that the paging lib. would need to reload the list. If getRefreshKey() returns null, then it will not know what page was last accessed and will return the user to the start of the list (as the key for position will be decided by the key in load()).

On the other hand, if getRefreshKey() is implemented properly, then: paging lib. will know the last accessed position and the list will not jump to the top. Instead it will show the last accessed page.

Upvotes: 16

mehul bisht
mehul bisht

Reputation: 742

As per the information here

getRefreshKey() provides a key used for the initial load for the next pagingSource due to invalidation of the existing pagingSource. The key is provided to load via LoadParams.key. The last accessed position can be retrieved via state.anchorPosition, which is typically the top-most or bottom-most item in the viewport due to access being triggered by binding items as they scroll into view.

and the description of Key states that

key passed to load after invalidation used for initial load of the next generation. The key returned by getRefreshKey should load pages centered around user's current viewport. If the correct key cannot be determined, null can be returned to allow load decide what default key to use.

Here, load is the Loading API for PagingSource.

Now I'm not about a use case which makes a difference about whether or not you should be passing a null key always, but it doesn't mention any disadvantage of passing null here and it states that load can decide a default key in case of a null key.

Upvotes: 3

Related Questions