How many simple Key-Value Pairs is too many for storing data in Android?

Question

I'm currently trying to save data in Key-Value Pairs using Shared Preferences in Android. Well I'm doing this the question seems to arise (Considering I'm saving a decent chunk of data.) How many different Key Value pairs is considered still OK to save in my App? I'm currently looking at saving 100 to 150 different values. (All still having unique key string names.) Is that too much data to be storing with Shared Preferences?

This may be a stupid question, but the only stupid question is the one left unasked, and I couldn't seem to find an answer. Only knowledge I came by is that you should only save Primitive values using Shared Preferences. (Which I'm already doing so...) -Thank You

Answer 1

How many is too many is really a matter of opinion. However, it's worth being aware how SharedPreferences work in order to get a feel for whether usingSharedPreferences` is the way to go.

As far as I know, there is no hard limit on the size of SharedPreferences, but SharedPreferences are stored in an XML file and when you first access the SharedPreferences the whole file is read and stored in memory so this in itself has an impact on the heap space used by your app and could lead to out of memory errors (partly depending on the size of the data, the available memory and what memory usage the rest of your app requires). Therefore, using SharedPreferences for a large amount of data will often mean you're using more memory than necessary. If you're reading the data from SharedPreferences into another data structure, you'll then have this data in memory twice. Also, XML isn't very efficient in terms of the space used on the filesystem.

I'm not saying it's wrong to use SharedPreferences but there's often a tradeoff between using something that might be more memory efficient (e.g SQLite DB) and give you extra functionality (searching, transaction support, etc.), compared to the simplicity of using SharedPreferences.

It also partly depends what you're storing - e.g. whether you're storing boolean values or long strings makes a huge difference in terms of memory usage. What you're doing with the data might make a difference as to which is the right way to go too. Do you need it to be scalable (e.g. you're storing 100 to 150 values now, but could that increase?).

If I were you, I'd consider how big my data is (i.e. amount of memory used not just number of key value pairs)? Might I need to store more in future? Would the extra functionality of SQLite be useful?

My gut feel based on the limited information you've provided is that I'd probably use SQLite, but I'm basing that on assumptions that scalability might be important and you're storing strings of more than a few characters, and even then I'm sure some people will disagree because "How much is too much" is subjective in this case.