Is it somehow bad practice to store Objects as JSON Strings in SharedPreferences in Android?

Question

As someone who recently discovered the beauty of simplicity of a NoSQL document store (namley CouchDB) I find myself very tempting when needing to persistently store simple Objects or small Arrays to use a Json serializer to store this data as a JSON String in the shared preferences. The advantages I see are:

• No added complexity, since (in my project) I already have a JSON Framework for my REST API that easily converts JSON/Objects
• I additionally would argue: less complexity since I can just use a POJO and don't have to take care of key/values manually
• In contrast to Java serilization or Androids parcable it is more or less a universal format easy to understand even for humans and easy to parse troughout different Frameworks
• With the correct tooling its easy to handle the update case where the data model changes and the config must be migrated (ignore unkown properties and set new defaults in Jackson e.g.)
• Again with the correct tooling, serialization can be done in a single line of code: mapper.writeValueAsString(myObject);

The disadvantages I see:

• Slow if using the comfortable way of serialzition (Databinding in Jackson e.g.) - but I'm not sure this plays any role in the "save config" use case
• Needs marginally more space - again I guess this negligible

Im aware that this approach is only feasible with reasonable small data (but the same applies for SharedPreferences in general, I guess) and the performance hit is negligible if this is only used on a "save config" or similar use cases where writes/reads are sparse.

Im looking for an argument for/against this approach in the depicted scenario or for problems I overlooked or may arise.

Answer 1

So after a couple of years here are my findings:

• Json serialization can be slow when using reflection based serialization and especially if the content is complex and/or long
• Specific care has to be taken into consideration when using Proguard to not obfuscate the names of the models to serialize.
• Migration is hard - this is to me the biggest drawback.

So it depends on the use case. Maybe for a cache this might be ok, since it is just performance penalty if the data gets corrupt after an update, on the other side caches should be fast (a memory layer could mitigate that).

If you need a data storage for structred data, use a database or ORM like Google's Room.

Answer 2

There's no harm storing small data objects in SharedPreferences. However, one thing you should keep in mind that SharedPreferences does not work properly across multiple processes. So you should avoid using SharedPreferences if you're planning to use them across processes.