Just for information, if custom, locally-generated data must be displayed with Paging-3, the code shown in Google’s guide & reference documentation will not work when invalidating the PagingSource. I could not find any real example so I observed the values in and out of the PagingSource generated by Room to work around the problem.
For an example of how it has to be made in order to avoid visual glitches and scroll bar issues, see this StackOverflow question and the related github.
Something else I’m curious about: in real-life applications, besides the insert & delete requirements I’ve already mentioned, the list must also be presented at a specific position first, like for example today’s news, or the last read post. So the developer needs a way to load the data at a specific position.
Unfortunately Paging-3 doesn’t offer more than what we had before, which usually means the developer has to create their own LayoutManager to be able to scroll at the correct position (the default implementation being erratic).
Furthermore, scrolling at a position makes the Pager load all the data between the first item to the position, which in a real-case means hundreds or more likely thousands of them.
If anyone found a solution to work around this limitation, I’d be happy to read about it, but at the moment, this and the other problems when using it without Room-generated PagingSource doesn’t inspire confidence. I would advise to use a ListAdapter and manage the loading / discarding manually, it’s much easier, more efficient and probably safer.
Thank you @redglyph for this additional information. It will really help readers while deciding whether to adopt paging three in their apps. In case I come across solutions to your problems I’ll definitely share.
I cannot edit my 1st post but just in case someone wants to use paging-3, I found and wrote the solution in the SO above. I had to spy how the Room implementation did. I have reported that to the Google team but they are very slow to respond and couldn’t really help much.
Regarding the 2nd issue of loading at a specific position or jumping at a position, I was unable to solve that and saw the same problem described by others. So we have to assume it’s not supported.
My conclusion: this lib handles asynchronous sources but seems very inefficient and does a lot of loading from the source, so if you have to use it in an app that doesn’t drain the battery too much, or if you need to display the data at a specific position, think twice.
I’ve reimplemented the functionality around ListAdapter, the source and its view model; it was the best option.