I know that SQLite is technically designed for large amount of data when SharedPreferences are easier and faster for simple data types.
I want to store simple true false boolean for every day in a year. This means I either have to create 3 dimensional json and store it as string in shared preferences (or rather to dimensional array with year as key) or create table with year month and data as separate columns (or it could be simple date column... that being said I can also use "YYYY-MM-DD" as key in sharedPreferences for 365 booleans).
Now here's the question. Should I use more complex SQLite database for storing this simple data if I'm 100% sure I won't need any searching/grouping/selecting by special parameter capabilities. Because it seems to me that if I need to store simple boolean (even in case of 365+ booleans total) I should use SharedPreferences since it's a faster solution. But it just seems kind of wrong to me since I'm not sure whether SharedPreferences are supposed to store this much variables.
Add:
These booleans are stored locally only for offline load or rather faster access to from user perspective. These 1|0 values are stored on server for each app user so even if I would do some complex work with data, I'm not sure if I need to do it on a phone.
shared preferences can take 365 values .Max size of shared preferences is about 1.4mb according to this.How ever share prefs are generally used to save very small amount of data like volume or user settings. I would recommend you to go with sqlite database.It take some time to set it up but it would worth the time spent
Storing your data in shared prefs may seem like a good idea, in fact it will just work fine, but it's taking an easy way. You never know what could you possibly need in the future. Your requirements are fulfilled at the moment, but it does not scale in any way. In general it's worth investing a little time and set up things properly and benefit in a long run.
Of course if you are doing some rapid prototyping or a quick demo it's a different story.
Setting a "complex db" or whatever does not have to be time consuming. Try Realm it's really fast.
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 know similar question to this one has been asked a numerous times, and surfing through SO I partially found an answer, but not complete, and android docs don't really help. Obviously I know how they work and have used shared preferences many times before, but I am wondering at what point ( how many ) is too much, I've read people had ~ 100KBS stored without any problem. Long story short --
Did someone actually had problems with too many data stored in shared preferences and what was problem, does data get deleted or?
** this is only a question out of curiosity, I already have my large values stored in SQL DB, just wondered what would be and if there would be any problems if someone for some reason stored everything in shared preferences
Since SharedPreferences are stored in an XML file, and therefore lacks the strong transaction support of SQLite, I would not recommend storing "100KBS" in SharedPreferences.
That being said, the lowest size limit that I am aware of will be your amount of free heap space, as SharedPreferences reads that entire XML file's contents into memory.
There is a limitations of SharedPreference data. In my case it throw a Memory Exception when SharedPreference data cross 1428.51-kb.
So its better to use SQLite database when you required huge data to store.
From reading your question I would think that you should not be using SharedPreferences, because (a) they are intended for storing much smaller amounts of data (hence the use of XML), and (b) there are many simple alternatives.
The only thing 'special' about SharedPreferences is the integration with the Preferences Activity for showing your preferences to the user, and that is probably not applicable in your case based on the amount you plan to store. (Oh, also the SharePreferences handles concurrency issues for you.)
You could use Java's serialization to store Preference class(s) in binary files. These would be dramatically smaller then comparable PreferenceFile and can easily be passed through GZIPInputStream to make it smaller (or CipherInputStream) to encrypt it. I have found this alternate to be a powerful, simple, and cross-platform way to store app data where the power of SQLite is not needed.
(Sorry this isn't a direct answer.)
So I inherited this Android project from someone else. The code currently seems to be storing huge amounts of data (that should really belong to an SQLite database) into the shared preferences. I'm very uncomfortable with that part of the code and want to start using the sqlite database. But I am still unable to justify to myself the time it would take especially if it comes with no immediate benefits.
Of course I'm eventually going to move it to sqlite but since I'm kinda on a tight deadline I was wondering if this is worth something doing now or later.
Any thoughts and comments on storing large amounts of data in shared preferences would be very much appreciated.
Thanks
If it works now then you can definitely leave it. You are correct that the large amounts of data should go into the database. If nothing else, you'll have an easier time of querying for data.
Further research has found this post suggesting that you won't have any major problems with a large amount of data in your Shared Prefs. You could, however, have performance issues since the single Shared Pref XML file will have to be read to get any pref while with a database you only have to grab what you need as you need it.
TL;DR; Don't use shared prefs for large storage, use a DB instead (but if it works for now and you're in a rush do it later)
I wouldn't personally recommend it since the system will keep an in-memory copy of all shared prefs for your app. So if you throw a lot of data in there your memory usage will be affected. That said, and depending on the data format (whether you can use it as is and use the key to find it directly - if you just store a huge JSON object that you then have to parse or if you have to get all shared prefs to then do a linear search for the one you really need, there's little benefit in either case) and how often you have to access it, it might be faster to lookup than a file or a database since it's already in memory. It also provides the benefit of being threadsafe (a SQL DB would be as well since DBs get locked when accessed) as opposed to a file where you would have to deal with that on your own.
Hope this helps.