search

digitalbuddha / RxStarter

Showcase Project using RxJava and RxDAO pattern
75 stars 5 forks source link

Please add the database persistence in your starter kit :) #4

Open javajack opened 9 years ago

javajack commented 9 years ago

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 !

digitalbuddha commented 9 years ago

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.

javajack commented 9 years ago

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 ?

digitalbuddha commented 9 years ago

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.

javajack commented 9 years ago

Alright. Look forward to you learn your disk storage implementation. :) The overall code structure is worth learning.

javajack commented 9 years ago

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 ) ?

digitalbuddha commented 9 years ago

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.

javajack commented 9 years ago

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 :)