Android - Shared Preferences are lost sometimes

Question

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 reb

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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