Architecture-components-samples: PagingWithNetwork: loadAfter() not working correctly after invalidate() is called

Created on 31 May 2018  路  7Comments  路  Source: android/architecture-components-samples

Using the PagingWithNetwork and Network only (by page). Change the pageSize to 1 or 2 in SubRedditViewModel. Then, after a swipe-to-refresh (so invalidate() is called) the loadAfter() method is not called anymore. Any recommendation to avoid this?

(I am having same behavior in my app with a higher page size)

Most helpful comment

This problem because of your refreshed data is same to old data ,cause adapter don't perform getItem(),so it can't perform loadAround() and loadAfter().

All 7 comments

me too

You probably used the LivePagedListBuilder class, which try to used the mList.getLastKey() for your new PagedList.
More detail on LivePagedListBuilder.create method.

And IMHO there should be an option to switch off the "inherit the last key" behavior.

Same issue...

Did you solve this problem?

This problem because of your refreshed data is same to old data ,cause adapter don't perform getItem(),so it can't perform loadAround() and loadAfter().

My solution is each time before refreshing, call:
adapter.submitList(null)
Then use:
datasource.invalidate()

but it was ugly...

My solution is each time before refreshing, call:
adapter.submitList(null)
Then use:
datasource.invalidate()

but it was ugly...

if u do this the DiffUtil will be useless ,the adapter refresh is low efficiency

This issue was also filed in the library bug tracker as https://issuetracker.google.com/issues/113122599

This problem because your refreshed data is same to old data ,cause adapter don't perform getItem(), so it can't perform loadAround() and loadAfter().

To add more detail here, it's because the initial load size fits within the viewport, and nothing changed. If the adapter sees nothing changed in viewport and the user can't scroll, there's nothing to trigger further loads.

We put in a sort of workaround in 2.1.0 (alpha), but as said in the bug and release notes, the real fix is having a large enough initial load size. The initial load size defaults to 3x page size - change your initial load size to be larger (with Config.Builder.setInitialLoadSizeHint()), and the problem will go away.

Was this page helpful?
0 / 5 - 0 ratings