anony_root
anony_root

Reputation: 1527

Is it bad to store "JSON.stringify" data in SharedPreferences?

I can't choose between SQLite and SharedPreferences.

I can use

JSON.parse(SharedPreferences.getString("data","qweqwe");

and

s.putString(key,JSON.stringify(JSONObject));

Or create a new, big class to store my (text) data in SQLite. (PS: JSON.* is my own class)

What will be faster, better?

I know that SharedPreferences is for "key-value" data, SQLite - for big amount of structured data. But in my case storing JSON-formatted data in SP and accessing by key would be easier. Main question - will it be slower or faster? Pros and cons?

Upvotes: 3

Views: 2436

Answers (3)

anony_root
anony_root

Reputation: 1527

I thought about this and had some practice.

So, using SQLite (in my case) is better that using JSON-formatted string in SharedPreferences, because I can just update only one-two rows from a table. With SharedPreferences I have to:

  1. use new JSONObject(sharedPreferences.getString("json_string","qweqwe");
  2. some manipulations with object
  3. edit my SharedPreferences.
  4. seasoning to your taste
  5. Put my JSONObject().toString() back into SharedPreferences. It's all.

IMHO, it's more complicated for the device. Because it cannot be seasoned

If I wouldn't need to update an individual parts of data, I'd rather to use SharedPreferences, because for static data, which I don't need to update, is faster.

Upvotes: 2

Squonk
Squonk

Reputation: 48871

On the one hand this is a slightly subjective question (and not the best fit for stackoverflow). On the other hand, taking your question title literally, the objective answer is "No, it's not bad".

The reasoning is, however, slightly subjective as it 'depends' on the situation.

The SharedPreferences class is effectively a wrapper / helper for a file stored in an app's private (internal) storage - as I understand it, it's an XML file. Based on that fact, ask yourself again..."Is it bad to save a JSON-formatted string in an XML file"?

As you mention in the commen on your question, using a SQLite database will mean writing extra code whereas the advantage of SharedPreferences is that a given preference file is accesible by name by any Android class which extends Context including Application, Activity and Service.

Upvotes: 2

Zambotron
Zambotron

Reputation: 699

I have used this approach in several projects without any issues so far. But there are certainly several advantages to using an SQLite database; particularly, the versioning/upgrade features of SQLite, and the powerful SQL querying language. If you ever need to migrate data to a new structure of storage, the upgrade and onUpgrade callbacks in the SQLite framework can be immensely helpful.

If you are keeping it simple, JSON in preferences can be very quick and extremely easy to implement. In terms of security, preferences are slightly more "exposed" than a database in that they are simply stored in xml, but ultimately the database file for an SQLite database is stored the same way and can be read during an intrusion as well.

I haven't had any performance issues using JSON/SharedPreferences yet, but I also haven't done any profiling to test this. My mindset has been to keep the code simple and not optimize prematurely - if performance issues arise, do the work of profiling it at that point.

Ultimately, I'd say that there is nothing inherently wrong with using SharedPreferences in this manner.

Upvotes: 1

Related Questions