I have an android app in which users have sets of items, and each item has about 10 properties.
What I do at the moment:
- items are stored in the server database
- when the user logs in, I get all the items (say 37) via the API and put them in a LinkedHashSet< UserItem > (UserItem is a POJO with setters and getters)
- then I get the 37 items from the set and put them in the local SQLite database
- when the user opens “My Items” screen in the app, i get the 37 items from the local SQLite DB
I was thinking, is this a good practice? Could I circumvent Step 3(storing items in the local database), but instead maintain the life of that LinkedHashSet object and get the items directly from there. If Im right with this suggestion, how do I do that?
I asked a similar question at Stack Overflow but I was told that I should come here and ask it.
1
As it’s been said in the other answer, you could maintain your LinkedHashSet POJO. In this post, it’s explained how to persist a global variable for all the life cycle of the application (it involves extending android.app.Application). This is the fastest way to read and write your data. You can expose it again to local storage or your server DB if you want to. The disadvantage is that if you somehow were to lose that memory, then the changes the user made will be lost.
If you need to sync the data with your sever, then see here for some suggestions on how to update both the data in the device and your server. This will be slower, as you have mentioned yourself.
From here, you can mix both strategies and find a very good solution for your app. Maybe you can program sync routines that are not as aggressive as to impact user experience, maybe you persist in local storage only when the data changes. You’d have three places to store data, with trade-offs of speed vs data safety.
Good luck!