Specifically, I'm looking for guidance on how to tie Store, Paging3, and SqlDelight together.
In a perfect world, Store wouldn't need to be part of the equation -- I should just be able to use Paging3+SqlDelight. However, that puts me in a weird situation: when I need paging, I use use Some Repository Pattern Type 1, and when I don't need paging, I use Store/Some Other Repository Pattern. In essence, it seems to me that Paging is an implementation detail, and that Store (or whatever my Repo layer is) should abstract over that.
Suggestion 1 - Paging-specific artifact
Store adds a new *-paging3 artifact that pegs a new withPaging(androidx.paging.PagingSource) builder method onto the StoreBuilder. The builder then provides a standard Store object that also happens to implement the RemoteMediator interface. (As an aside, if you squint, RemoteMediator looks pretty similar to the Store signature).
Using this Store|RemoteMediator, I can then wire the downstream paging dependencies as necessary -- the Repository (i.e. Store) papers over the DB+Network (as Store already does) and handles the request of new info as the viewport changes (as Paging does).
Suggestion 2 - Code Sample
Something like the above could be a PITA to maintain, especially since Paging3 is still in alpha...I'd also be happy with guidance on how to tie a non-Room DB to Paging using Store as an intermediary. That could be in the form of a sample, or a wiki...dealer's choice!
BTW Store is a super cool library, thanks for all the time and effort y'all spent on it 😄
Specifically, I'm looking for guidance on how to tie Store, Paging3, and SqlDelight together.
In a perfect world, Store wouldn't need to be part of the equation -- I should just be able to use Paging3+SqlDelight. However, that puts me in a weird situation: when I need paging, I use use Some Repository Pattern Type 1, and when I don't need paging, I use Store/Some Other Repository Pattern. In essence, it seems to me that Paging is an implementation detail, and that Store (or whatever my Repo layer is) should abstract over that.
Suggestion 1 - Paging-specific artifact
Store adds a new
*-paging3artifact that pegs a newwithPaging(androidx.paging.PagingSource)builder method onto theStoreBuilder. The builder then provides a standard Store object that also happens to implement theRemoteMediatorinterface. (As an aside, if you squint,RemoteMediatorlooks pretty similar to the Store signature).Using this Store|RemoteMediator, I can then wire the downstream paging dependencies as necessary -- the Repository (i.e. Store) papers over the DB+Network (as Store already does) and handles the request of new info as the viewport changes (as Paging does).
Suggestion 2 - Code Sample
Something like the above could be a PITA to maintain, especially since Paging3 is still in alpha...I'd also be happy with guidance on how to tie a non-Room DB to Paging using Store as an intermediary. That could be in the form of a sample, or a wiki...dealer's choice!
BTW Store is a super cool library, thanks for all the time and effort y'all spent on it 😄