RxStarter
RxStarter copied to clipboard
digitalbuddha
Please add the database persistence in your starter kit :)
Many applications would like to store the REST received data locally and bring fresh data only from REST to reduce the chattiness between Android App and REST Service as well as to make offline data access possible.
You have very well covered the REST to UI approach. The only missing link in your starter kit is REST to DB to UI approach.
What is your "best" approach for the same , which library for local db access ? Is it feasible for you to add that code in your current starter kit ? I would be very useful addition and would make this code base complete reference for CRUD scenarios !
Make sense. I try to avoid sql lite and instead persist objects directly to disk. I'll add disk persistence to the commander shortly. Overall concept: when commander saves to in memory Cache also save to disk, when loading from in memory Cache if null then check from disk prior to network.
One more thing, I am able to look up only 30 items. After that I get an index related exception once and thereafter I don't get any error, nor the github users get looked up.
Where is this hard limit of 30 list items defined in our code ?
Github api only returns 30 items at a time (try plugging the url into a browser). I think there's a pagination parameter that you can look into adding if you need more results. You could also add something to the nextUser observable to check if index is less than the size of the list return.
Alright. Look forward to you learn your disk storage implementation. :) The overall code structure is worth learning.
I just bumped upon a reactive sqlite library.
https://github.com/square/sqlbrite
Since your project is themed around making optimum use of rx-java does it make sense to use something like this as a data store ( wrt the above discussion ) ?
becomes sloppy with joins. You'd have to iterate through each object and save the sub objects separately, same thing when you fetch. For most use cases I've found storing objects directly to be more optimal.
I see. Reason your approach with statement or two when you commit, it might help others digest why not going SQL way is useful. Look forward to the commit :)