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.
Related
I'm currently developing an android app in which I'm dealing with php files that returns json, the json then gets parsed and is used to fill up an arraylist of different objects.
What I'm trying to do is, I want to cache these objects in case of no internet so I can reload them and make the application useable offline.
Currently I have 2 solutions for this:
A) Make an SQLite database and creare tables with the same structure as the objects I'm trying to cache and then reload them on startup
B) Save the JSON strings inside the shared prefs and parse them on startup.
I didn't really find any best practices or tutorials when I came across data caching so I'm lost now and I have no idea what to do. So if you guys can please help out I'd be thankful.
You might find the following talk interesting:
https://www.youtube.com/watch?v=xHXn3Kg2IQE
As you can see, a lot of scaffolding goes into the ContentProvider approach. For a very simple app, it can be acceptable to just cache some JSON in a SharedPreferences. However, as your app becomes more complex, the advantages of the ContentProvider will be worth it.
You can use files instead of sqlite and shared preferences.
Shared prefrences is using for small data.
Sqlite is using when you need to make queries on stored data.
So I think it's better to cache in files, or if you are using something like retrofit or any network lib you can check if they support caching and use it.
Definitely not option B. Shares preferences are not suitable for storing large amounts of data. It's XML so cannot be queried like Sqlite. The time to retrieve a single item will increase linearly with the amount of data stored. Secondly JSON will have special character these will need to be escaped which means the storage size will increase even more.
There is however an option C. Using cache files. This approach and other store options available to you are described in the google developer guide and this is essential reading.
So in summary: you options are to parse the JSON and store it in sqlite or to save the json as a file in the cache directory.
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.)
In my android application I have to store some application settings and some user information within the phone.
I can go for the shared preference option explained in this DOCUMENTATION.
But wondering if I can store data as objects wise within the phone. I found this Stackoverflow Question regarding saving serialized objects in files and bit not sure of any issues if I go with this way to store persistent data.
Also would like to know what the best way to deal with insert/delete/update and read with XML files in android. Would appreciate any guidance. Thanks in advance...!!!
If it is only a small amount of data you need to store, then go with the built-in shared preferences, that is what the functionality is there for. SQLite and OrmLite are a bit heavyweight in this situation IMO. Even if you want to handle the data as Objects; in which case I would serialise to / deserialise from JSON or XML stored in text files and handle the insert/update/delete on the deserialised objects in your model.
If you want to persist some objects I think you should use SQLiteDatabase, it would be a more cleaner solution than using serialization in files. You will indeed need to write some extra code for your Database but you will end up with a cleaner implementation in my opinion. You could also be using OrmLite for Android which is pretty robust and easy to use if you have some basic orm knowledge.
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
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.