Status Update
No update yet.
Comments
au...@gmail.com
Would be nice if we could easily integrate Paging library with existing DBaaS solutions (MongoDB Realm, Firebase, etc). These services already have SDKs which gives observable list of items per query/page.
- [page1] = limit 25 observable (Flow<List<Item>>)
- [page2] = limit 25 from lastItem (Flow<List<Item>>)
- [page3] = limit 25 from lastItem (Flow<List<Item>>)
- <...>
all list is = flow0 + flow1 + flow2 +...
ri...@soundcloud.com
For us such a feature would be really useful. This is our use case: In our app we usually have a data source that returns a list of items, for instance an endpoint that returns a paginated list of tracks. We enrich the items in these pages using data coming from a few more data sources that could emit as many times as some state changes (i.e a track is liked, the playback state changes, etc).
ma...@marcardar.com
ka...@gmail.com
We need to update single item and add single item.
du...@google.com
Currently the only way to update items / add items is via PagingSource.invalidate or transformations on PagingData. For the most common cases this should work pretty well, but this ticket is open to provide a better stream-based API to achieve this, and also better support frequent granular updates.
nd...@gmail.com
I'm working on an App where I currently rely heavily on Room and Flow to update my lists (status icons, download progress on individual items), wouldn't hesitate to integrate Paging if something like this was integrated.
[Deleted User] <[Deleted User]>
ne...@gmail.com
c4...@gmail.com
al...@pierlis.com
ge...@gmail.com
du...@google.com
To be clear, adding this feature does not change how you should use Paging with Room - you should still update the DB (which propagates invalidation and reloads anyway). Otherwise config-changes, refreshes, drops / reloads, fast-scroll, etc.. will cause your updates to get "reverted". Part of the architecture of Paging is having a single source of truth to prevent this kind of common mistake - however this feature is still super useful in use-cases like Realm, which support notifying of DB writes in "windows".
cc...@google.com
du...@google.com
cl...@google.com
co...@gmail.com
pu...@gmail.com
Now, for user to interact something on the view, which would call the viewmodel to POST something on backend and based on the result, change the UI a bit is impossible, without actually invalidating the list and calling the backend again to update the current view. No, I am not using any Local storage for this. Our source of truth is backend. This is so silly
qw...@gmail.com
cl...@google.com
Re:
aa...@gmail.com
use case: in case of horizontal recycler view inside vertical recycler view (e.g. OTT like app).
Pages can be fetched from one source But in some horizontal list source can be different like: continue watch / my list .. and just to update one horizontal rv we need to invalidate whole paged data. Isn't it unnecessary load on low end devices like TV ?
cl...@google.com
Re
For your use case, I would highly suggest using different adapters for each nested horizontal RV. This is crucial so that
- Paging can individually track scroll state of each horizontal row
- You only need to invalidate data for one row
Or you're probably already doing that and your implementation would invalidate all inner PagingSource whenever the outer PagingSource is invalidated?
But I understand where you're coming from and self-updating Paging is still something we intend to address.
aa...@gmail.com
Definitely update can be done by using individual row's paging source.
looks like I missed - Use Case:
suppose user can add or remove items in MyList (lets assume we have MyList horizontal row at position x in our vertical list - where vertical list has its own network backed paging source - which tells us to show MyList at position x )
1. when all items are removed from MyList we need to remove MyList from our vertical list.
2. when first item is added in MyList we need to add MyList in vertical list at same position.
For these we need to make change in vertical list.
so how this is possible ?
cl...@google.com
I see. I understand your use case. To emphasize, we still want to implement self-updating Paging. This is not abandoned.
an...@gmail.com
Hi, I'd like to add one more possible use case to consider.
I am involved in Tusky, a client for "Mastodon" (think Twitter but Linux). We are attempting to switch to paging3 for our displayed lists (timelines of posts, lists of notifications). We have one particular feature which seems to be incompatible with paging3 currently:
Imagine you read some posts on Mastodon, you set down your phone, you come back 12 hours later. The app goes to load more posts, but discovers there are many, many posts, more than would be convenient to display. Instead of loading the next page of posts, the app places a button saying "LOAD MORE" above the previously loaded posts. Above that it puts the newest page of posts. If you tap "LOAD MORE", the app can then load page [PRESENT]-1 or [PAST]+1 above or below the "LOAD MORE" button (and if more pages still remain between present and past, stick another "LOAD MORE" button in between.
This is a pretty common idiom, but it seems to be impossible in Paging3 because there is no way to insert pages "in the middle" between two other pages. It only seems to be possible to add to the head or the tail, or to invalidate the entire list (from our perspective a heavyweight operation). The only solution we've found to this is to simply drop the "LOAD MORE" feature, which may have been a good idea for other reasons, but it's too bad if we're having to drop features because paging3 does not support them rather than because we specifically decided the program would be better about this.
(In addition to this, as with other posters in this thread, we are also struggling with the ability to update a single row out of the dataset, something we need because posts on Mastodon can be deleted or edited by their posters after we have already displayed them. We have a solution for this but so far it doesn't work so great.)
Description
Currently, Paging expects immutable gradually-loading snapshots to be returned from PagingSource, and that any content changes come through invalidate and re-load.
This works fine for Room's behavior around SQLite, or a pull-only network API that doesn't update individual items, but may not work for other cases.
The feature here would likely be a new
Currently:
Page<T>(data: List<T>, ...)Self updating version could be:
UpdatingPage<T>(data: Flow<List<T>>, ...)I'd appreciate if others could chime in about how useful this would be, and about examples of data sources that would benefit from this.
One constraint to making this work is that we'll likely need to assume these item updates don't affect separator positions (until items are dropped and reloaded).