I need persistent storage for my application for a certain activity. I was going to initially use a database table with 5 columns for holding the data I needed, but then I thought that maybe using sharedPreferences may be lighter weight in this case. So my question essentially is, if I am going to use a database for a single entry, should I just use sharedPreferences because I know databases are known for being a bit heavy.
If you just want to store the 5 values, then using SharedPreference might be preferable. It is also faster than using database. In addition to allow persisting key-value pairs, SharedPreference also supports saving sets and ArrayList.
See Save ArrayList to SharedPreferences. So storing an array in the ShraredPrefernce will suffice.
If you have more structured data, then using database might be better to manage. To know more about when SharedPreference would be good to use and when SQL Lite database, Pros and Cons of SQLite and Shared Preferences question is a good read. Hope this helps.
Yes, sharedPreferences works great for what you are trying to do. It's lightweight and needs the least amount of code to meet your requirement.
Related
I know there are some topics and posts about this question, but i want to have an individual feedback.
So in my app i use one shared preferences (file) and gson to store a list of objects, containing big amount of data. So my shared preference file is about 5 MB big and contains ca 1 Mio characters. I know this sounds not really good, but my app works perfectly. No long loading or saving times.
I choose this method, because i ONLY want to store the data, when my app will be closed and between app starts.
I know really good, that shared prefs is not a good way and actually meant for saving small strings for preferences.
So do i have to change this method or is it "okay"? Or does someone know a good solution, which is easy to use and understand, because for me sqlite is difficult and hard to use. Or is there a easy way to store an object into sql? (Maybe a library or a method??)
Thank you in advanced!
Rule of thumb: As long as it works does not necessarily mean it's good. Said that, SQLite is a perfectly valid solution for android applications. There is also a handy developer guide on how to save data with SQLite, but the recommended approach is actually to use the Room Persistence Library.
No, it is not meant for big data objects. For that for example you can use SQLite internal database
for temporary bases it is good for store a data in shared preference. If you want to store a big data then you have to use SqLite to store your data in your device.
Would reading SharedPreferences every two hours or so alongside polling in an android application be wasteful of a user's resources?
You can do it, is not significantly expansive about computation.
Of course, it depends on your data; if you store a huge JSON data structure, the read will be more weight than if you use a couple of strings.
How many information you have to store? If this information is not too much is not a problem for you.
I don't think so , eventually your SharedPreferences are going to be stored in an XML file , key and value pairs , bigger data structures is better to be persisted with sqlite
I have a question. In my project I have some user preferences which are stored in the SQL database. There are about 200 records and the table has 3 columns. This records do not change, only if the user is changed and the data is downloaded again. I want to put them in SharedPreferences because it would be easier to manipulate the code. The way it is now, it's a bit difficult as I make the queries asynchronous. Now, my question is: Is the number of records to large for SharedPrefrences? Or it should be no problem to store them there?
Shared Preferences:
All shared prefs are stored in /data/data/[package name]/shared_prefs/[app name].xml, so i think there's no limit based on aechitecture.
Shared Preferences is nothing but a simple table which has two columns. (key, value).
Shared Preference size 8192 characters according to this documentation:
http://developer.android.com/reference/java/util/prefs/Preferences.html#MAX_VALUE_LENGTH
advantages:
Fast retrieval
Easy to understand and program
disadvantages
Maintaining Keys are difficult if we store a lot of values.
User can clear this at any time.
Database:
When we have a lot of values to store with complex structure, we are left with only one great solution, ie. DB.
advantages
We can maintain structure of data.
Android has nice and simple APIs to handle sqlite operations.
disadvantages
Operation is little bit slow comparing to shared preferences.
user can clear this at any time.
Reference
I am making an application which is saving the values in arrays and I have 7 arrays like this. Now I want to save these values for future use although the application is restarted. I am confused between database and sharedprefrences. Pls tell me what I can use for this approach and why??
And if I use sharedpreferences then is there any way to store multiple rows of data or I can use SQLite only?? Please do tell.. Thanx in advance...
These two are 2 of the methods for saving persistent data. There are both pros and cons.
My opinion is that if you want to save a large amount of data I will go with the database. The preferences are more like saving states or valuable information that require a key-value pair. A simple example is saving the value of an EditText or how many times the user has logged in the application.
Although in your case the database might seem more appropriate, the implementation is a little time consuming and I don't know if it's worth it for your case. If there is a possibility of expanding the dataset that you wish to save then go with the database. It's up to you.
I hope this answer gave you a briefly overview.
One way is discussed here:
StackOverflow - How to Implement Persistent Storage in Android
Here's something that shows three different kinds of storage: Data Storage in Android
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?
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.
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:
use new JSONObject(sharedPreferences.getString("json_string","qweqwe");
some manipulations with object
edit my SharedPreferences.
seasoning to your taste
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.
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.