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.)
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.
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.
What are the disadvantages of using too much SharedPreferences on android?
If you try to do anything complicated with SharedPreferences quickly becomes very tedious; you can only store primitive types and it's a simple key/value system. So, there are no disadvantages per se, but SharedPreferences are meant for lightweight storage of simple data.
You should only use SharedPreferences to store small bits of data related to user configuration. It can only store basic data types, so if you have more complex bits of information, you should probably switch to another mechanism.
One convenient feature of SharedPreferences is that you can share data between two applications using it; so if you have two applications that have to share user preferences with each other, using SharedPreferences might be a convenient choice.
Also, you should not store large amounts of data in SharedPreferences; it's not made for that. Instead, use an SQLite database(1) for a more robust solution.
(1) http://developer.android.com/reference/android/database/sqlite/package-summary.html
Shared preference are for quick access and are loaded in the memory for fast access along with the application...so if you try to store large amount of data in shared preference...it is going to cause some more usage of critical memory of your app(and i guess if too big to store in memory some swapping would happen causing performance impacts).Better to use DB/file system/web server for huge data....by storing small quantities of information that are very often accessed by the app you can in-fact increase your application performance.
user can clear data which is stored in Shared preference at any time. this is the major drawback of Shared preference.
first point to be considered is shared preferences are non-volatile data. So they are stored as key-value pairs as your application data. So, using them extensively in your app might become complicated for you. And, coming to process throughput, it don't effect your app speed because these are stored in/as secondary storage.
I am writing a game and storing almost all active game data (stats, location etc...) in shared preferences.
This will, when all is said and done result in over 100 shared preferences used by my game. Of course the majority of those stored values are small integers or Boolean.
Since I don't need to do any sorting on the stored data, I don't really see a need to use a database.... unless there is some distinct advantage that I am not aware of.
Is there any reason why Shared Preferences should NOT be used in this way? Performance issues? Data Integrity issues? Anything?
Thanks in advance!
If the values remain small, and you don't need them to be structured (like if you have user profiles or something), then Shared Preferences should be just fine. 100 ints only amounts to 400 bytes, so even if the Shared Preferences were stored in memory, it's not a big deal.
There is no limit on the number of shared preferences (except for storage space), but these are currently written as a single XML file for the entire shared preference object, so you
don't want to go crazy with how much you put there. 100 preferences shouldnt be an issue, and it allows a quicker and simpler access to data compared to databases or flat files etc.
It is actually an xml file. In your case, there is certainly no problem for your concerns.
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.