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.
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.
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