-
Notifications
You must be signed in to change notification settings - Fork 203
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Store + SqlDelight + Paging3 Guidance #250
Comments
Hello just checking in, I don't have a good answer/solution as of yet. |
Hi @digitalbuddha , Im interested to work on this issue as a part of GSoC2022. Kindly guide me through the next steps |
Hi folks hold tight, there will be some messaging from dropbox coming along with how to join the google summer of code projects |
Ok thanks. |
Hello @digitalbuddha, I'm very interested in working on this project as a part of GSoC 2022. Further guidance for the onboarding process would be much appriciated. |
Due to some personnel transitions, we unfortunately had to pull Store from GSOC2022. We sincerely apologize for the inconvenience |
|
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 newwithPaging(androidx.paging.PagingSource)
builder method onto theStoreBuilder
. The builder then provides a standard Store object that also happens to implement theRemoteMediator
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 😄
The text was updated successfully, but these errors were encountered: