Reputation: 1527
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
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:
new JSONObject(sharedPreferences.getString("json_string","qweqwe");
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
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
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