I have an app that only requires the value of a textview field to be saved... what would be the most simple and efficient way to save such a small amount of data? Creating a database for this seems like overkill. would onSaveInstanceState be sufficient?
This sounds like a job for SharedPreferences.
You could also consider saving it to cache. Keep in mind if you use internal storage for your cache, it may be deleted if there is low memory. Using Shared preferences also works as Yoni had mentioned and will ensure that the data is not deleted even if on low memory.
SharedPreferences is the easiest if you want it to be persisted across sessions.
I think onSaveInstanceState will not survive a closing of the whole application like it will happen if you shut down the phone or your app crashes.
Go with the sharedPreferences Yoni mentioned. They will make your data persistent on the phone memory without much work for you.
Related
I want to write an android calculator app like the one on my android phone. It saves history for operations and by clicking a button it shows last operations. Now my question is what is the best way to save operations? Is it reasonable to save them to a file in internal storage or what?
There's some options..
1) Include a SQLite Database, as others mentioned. This makes storing lots of information really easy. You can find tutorials on how to include one properly in your project, and don't hvae to care for much more. You can then work with content providers to read and store data.
http://developer.android.com/guide/topics/providers/content-providers.html
2) SharedPreferences. If you just intend to store like the last, or the last 3 Operations, you can just use shared Preferences. This is way less overhead than adding a Database, if it is a small project, albeit you will have to keep your data structured yourself.
http://developer.android.com/reference/android/content/SharedPreferences.html
3) If you just want to store the users current session you can just Keep a Stack of the used operations. On undo, or however you call it, you would just pop the stack.
By implementing onSaveInstanceState and Parcelable you can make sure that no data is lost on rotation / low memory and such.
I personally would advise you without knowing more about your project to use plain java objects and storing the state. A calculater would in most cases not need persistent storage. If you really want to know what the user did 2 weeks ago, you should use a Database.
I would recommend you to use database(SQLite) for storing the data.
If you don't know more about SQLite in android have a look at these
tutorials.
I think database should be handy for history if more than one operations has to be stored else for one operation you can use shared preference.
I'd like to develop an app which need some data persistency. For some reason, I don't want to use database. And I'd like something similar to the shared preference. But only have one more requirement:
I hope my data can be persistent across installation. That means even the app uninstalled the data still be stored in Android system safely.
Are there any suggestions? Thanks
P.S.: In iOS, I use the keychain.It works perfectly.
The only solution I can think of to ensure non-removal on uninstallation is to write a file somewhere on the external storage. However this is (a) insecure (b) prone to other issues such as users deleting it.
If you are worried about persisting data on upgrades then using a database with a ContentProvider you can achieve this fairly easily. Shared Prefs are only really meant for a small number of small values/primitives.
There is also the option of storing something remotely, with a web service if it fits with whatever need you have to retain data when uninstalled/reinstalled.
The majority of questions like yours indicate an issue somewhere else in the way your application is architected, if you provide more detail people here may give you a better solution
The only way I can think of doing it is syncing the data with the cloud and restoring it if the user reinstalls the app. You may want to look at leveraging the BackupManager.
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.
Some of the users of my application complain that sometimes (in a random way) the settings of my application are getting reverted to their default state (usually after a reboot of the phone). I never managed to reproduce the problem though. I am thinking it is due to the fact that in many places in my app I have a piece of code that calls the shared preferences editor and commits changes - Can it resolves in corrupting the shared preference file if I try to commit several changes to the same preference file at the same time? (Multi-thread application)
I am really lost. I tried to look in the web for hours to find a solution without a success.
If anyone has even an idea so I can start investigating, I would be grateful.
Thanks,
Amit Moran
I'd echo the other answers - that you need to avoid conflicts if you don't want to corrupt the file - and I'd go further to suggest that you're probably misuing SharedPreferences.
SPs are designed to store small pieces of information about your app - user settings like volume or whether music is playing or things like that.
SPs are NOT designed for storing data which changes often and/or large amounts of data and it's a bad idea to try to do this (for the reasons you've discovered and a few others).
Remember that SPs are really just an XML file - you're incurring the overhead of parsing and recreating that every time you change it too!
The idea of an App which updates SPs in more than one thread is a bit mad I think - you need a better way of managing and storing the data you're saving - it will pay-off for you in more than one way...
According to the SharedPreferences.Editor documentation:
Note that when two editors are modifying preferences at the same time, the last one to call commit wins.
From this I gather that multiple simultaneous commits will not wipe out your preferences, but it's possible that not all changes you are attempting to write will end up getting written if multiple Editor instances are being used simultaneously. To avoid this you could put all preference modifications in synchronized blocks or even use one synchronized static method for all preference writing.
I suggest you use a singleton to manage the preferences. Whether you do this by implementing a true java singleton, or by using Android's Application Context is up to you. (see this question for several good arguments for/against each)
For something like SharedPreferences, this is a good way to manage them especially for a multi-thread application. This will possibly eliminate some of the questioning of whether or not the commits are conflicting with each other. This may not be the whole problem, but it's somewhere to start.
I had a similar problem: my preferences had not been saved reliably. On some devices (in my case the XOOM-Tablet) data got sometimes lost and sometimes not. I've solved the problem by simply calling clear() on the editor before commiting new data.
Shared Preferences get lost after shutting down device or killing the app
I found I was losing a particular entry in SharedPreferences by opening the editor, doing a getString on it, and then committing without doing a putString on the entry first, even if there was no required change. Once I stubbed in a putString to save the value no matter what, the entry stopped vanishing after the commit.
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.