IssueTracker

If there were a PagingData.map { list -> } version i think it would solve my issue since i will be able to perform a single query by ids to fetch the progresses and then map the list

Hello, i’m facing a problem on some devices where i have a paging source with multiple tables query (relationships join) when the user clicks on an item from the list and navigates to the details page the details page refreshes the “progress” for the entity which is one of the paging source relationships which in turn invalidates the paging source, the details page have a list of items that also fetches a progress, when the user navigates back the list which is a paging source takes seconds to display the pages I noticed two things:

when the loaded pages are less the fastest the pages display

when i remove the “progress” relation from the paging source query the issue is completely gone and the list displayed quickly

This is another issue I’m facing too

Can you upload a sample project?

Hello, please find the attached sample project

My testing device is Samsung A31 the issue is more visible on this device than Pixels but i tweaked the values in the sample project to make the issue visible on Pixel 7 pro

Additional information my query was quite slow which made the issue more visible, but even after optimizing the query a small delay inside the pagingData.map blocks the pages from display when the paging source is invalidated frequently

Hello, Any update on this?

Not entirely sure how progress factors into your data flow but based on onPageLoaded callback, it seems you start progress at 0F after you load data from RemoteMediator.

I'm assuming you start progress when data is loaded and continually updates until 1F? Also looks like progress doesn't change any data on the ContentEntity itself.

So it sounds like content and progress should be separate flows instead of conflating content & progress into a single entity. After you load the data, fetch the progress flow to update your LinearProgressIndicator.

The uploaded sample project doesn’t reflect business logic, The real app is audio books and novels the progress is actually where the user left off and continue to update when exoplayer is playing i fetch the content along with its relations including progress to update the ui whenever the progress change I don’t believe i need two separate flows when i can simply join the progress or use Room relation annotation, the sample project shows a bug where the pages is blocked from being displayed because of the paging source keep being invalidated and a small delay inside pagingData.map were you able to reproduce this issue

In onPageLoaded i refresh the progress from the backend in the real app along with other on the fly boolean flags which updates the content entity table like if the user have enough credits to consume the content

I were able to fix the issue by excluding the progress from the paging source query as explained above but I believe there is a bug in the library and it should work either way that’s why i opened this issue

The issue with separating the content and the progress into two flows is that i need to fetch the progress for each page item individually which means n+1 query problem lets say i have a tablet which can display over 20 item at once at the screen that mean 20 read query with flow return type which will also be invalidated frequently because of the exoplayer updating the progress table every 0.5 seconds