0

I need to store few objects (less than 100, in the worst case) in my android app. Each of these objects contains: (1) A date object (2) Another structured object of mine (which includes short, float, char, string and boolean).

Storing the objects as string set of JSONs in shared preferences is the most easy solution, but does it the best for this amount in terms of performance? Should I stick with SQLite even though the small amount of data to store?

Mishums
  • 19
  • 6
  • I think you need to factor in how you are going to use the data once stored. SQLite would likely be the better option if you were going to manipulate the data such as sort the instances. – MikeT Nov 14 '16 at 22:01
  • I want to store the data ordered by the Date object that every object contains, no more than that. – Mishums Nov 15 '16 at 21:11
  • SQLite could be the simplest, as you could then extract the data, via a query that includes an ORDER clause, thus ensuring/enforcing the order irrespective of the order that they are added by. I don't think performance would be an issue with even hundreds. The overhead with SQLite is writing the code to handle the DB. However if using preferences then you'd need to write code to perform the sort unless you relied upon ensuring that they were correctly ordered when adding. Another complexity is with storing objects in shared preferences, there's quite a few q & A's in regard to this on SO..... – MikeT Nov 15 '16 at 23:58
  • continuing from previous comment:- e.g. [How Android SharedPreferences save/store object](http://stackoverflow.com/questions/7145606/how-android-sharedpreferences-save-store-object) – MikeT Nov 15 '16 at 23:58
  • Actually, I've forgot to mention that I'm mostly adding objects with the most recent date to the data. So when I'm thinking of that - the data set will stay sorted 99% of the time. In this case - would storing JSONs set in shared preferences be a good solution? – Mishums Nov 16 '16 at 17:05

0 Answers0