12

there are lots of questions out there related to shared preferences and the alternatives. My problem: when I shut down the device or kill the app, the shared preferences get lost. Please note that my code actually is working on Acer A500. But on my Motorola Xoom MZ604 it isn't working!!

First of all I try to restore my HashSet in onCreate. This method is called for sure and is implemented in a singleton.

public boolean restoreCollection(Context context){
    SharedPreferences settings = context.getSharedPreferences(context.getString(R.string.restore_values), 0);
    if(settings.getStringSet(context.getString(R.string.collection), null) != null){
        collection = settings.getStringSet(context.getString(R.string.collection), null);
        return true;
    } 
    collection = new HashSet<String>();
    return false;
}

By calling onDestroy I save the HashSet. Even though it isn't given, that this method is called for sure, the Preferences get lost in any case, I have trying to save it in onPause with the same result.

public void saveCollection(Context context){
    SharedPreferences settings = context.getSharedPreferences(context.getString(R.string.restore_values), 0);
    SharedPreferences.Editor e = settings.edit();
e.putStringSet(context.getString(R.string.collection), collection);
e.commit();
}

Has had anyone problems with Shared Preferences and the XOOM device,too or am I the only one? Perhaps something is fishy with my code but the data doesn't get lost on my Acer Tablet.

I've also tried PreferenceManager.getDefaultSharedPreferences(context) to get object of SharedPreferences

Thanks for your help, Chris

Gordon
  • 312,688
  • 75
  • 539
  • 559
Chris
  • 4,403
  • 4
  • 42
  • 54
  • 1
    have you checked the return value of `commit`? – mxk Mar 21 '12 at 11:45
  • 1
    Good point - but unfortunately: true... – Chris Mar 21 '12 at 12:17
  • I've never seen that happening on any device, and I've seen a lot (not tablets though, just phones). Since you mention yourself that it only happens on the Xoom, could this simply be a vendor specific issue? – mxk Mar 21 '12 at 17:59
  • Were you ever writing a null key ? See : http://stackoverflow.com/questions/5368442/android-getsharedpreferences-error-map-value-without-name-attribute-boolean/19621603#19621603 – Mr_and_Mrs_D Oct 30 '13 at 15:50
  • It turns out this can also be caused by invalid preference keys, such as keys containing newlines: http://stackoverflow.com/questions/28385132/sharedpreferences-in-android-not-persisted-to-disk-when-key-contains-newline – caw Feb 07 '15 at 17:29

3 Answers3

15

I was having the exact same issue when using string set with the SharedPreferences. I discovered why this was happening and how to resolve it.

Very important to read the API documentation for SharedPreferences.getStringSet (String key, Set defValues)

Essentially DON'T modify or touch the returned Set! If you do you will get odd results with the SharedPreferences. :)

Enjoy!

Jona
  • 13,325
  • 15
  • 86
  • 129
  • I agree but in addition, I'd say when and where you get the string is what is most important. Please see my answer: http://stackoverflow.com/questions/36939380/android-persistent-checkable-menu-in-custom-widget-after-reboot-android/36998250#36998250 – iOSAndroidWindowsMobileAppsDev May 03 '16 at 07:48
  • 1
    This solved the issue for me. The really annoying this is that you can modify/write it back and whenever you read from the prefs during the same run of your app, it shows the updated values fine, but it reverts to the old value whenever you start the app fresh. Most confusing thing to debug. – Nic Robertson Jul 13 '16 at 23:04
  • Thanks Jona! And another tip: when making a copy of the returned Set make sure it's a COPY and is not retaining a reference to the original set. You need to make a deep copy and persist that object back with your changes. – Lucy Feb 26 '23 at 13:24
15

I've figured out a solution that works both, on my Acer and on my XOOM device: you have to call clear() on the editor before committing new data:

public void saveCollection(Context context){
    SharedPreferences settings = context.getSharedPreferences(context.getString(R.string.restore_values), 0);
    SharedPreferences.Editor e = settings.edit();
    e.clear();
    e.putStringSet(context.getString(R.string.collection), collection);
    e.commit();
}
Chris
  • 4,403
  • 4
  • 42
  • 54
  • 1
    This solution is not working in my case I have the same issue that i'm not able to get Preferences in myLocationService on Xoom but on Galaxy Pop it's working fine. – MobileEvangelist Dec 06 '12 at 15:37
  • 2
    This is certainly not a solution - I mean preferences are meant to be persistent - most use cases would be nulled if one were to clear the prefs - the cause is elsewhere – Mr_and_Mrs_D Oct 30 '13 at 15:52
  • This works, but it is not the correct solution. See https://stackoverflow.com/a/31598304/238753. – Sam Oct 15 '17 at 05:15
3

Your problem seems to be the same as discussed here for the device Samsung Galaxy S running standard Froyo 2.2.1. Some impressions from their discussion:

The Log shows:

01-19 12:08:56.856 W/ApplicationContext( 4563): Attempt to read preferences file /dbdata/databases/com.mobilemerit.ultimatefaves/ shared_prefs/com.mobilemerit.ultimatefaves_preferences.xml without permission

One possible workaround seems to be:

My user seem to have had the same symptom.

He e-mailed me that he had to do a factory-reset to his phone due to other reasons, he re-installed the app from the market (something that didn't help before the reset), and now everything works as expected.

Another workaround:

I have the same problems with my 2.2.1 Galaxy S (rooted), I solve it by deleting my app folder (com.xxx) in \dbdata\databases. Does someone have the same problem on another phone ?

And this guy actually found the cause of it:

I installed my app (WidgetLocker) and it got app_81, then I uninstalled using "adb uninstall com.teslacoilsw.widgetlocker" then reinstalled and found my preferences had persisted across the uninstall, but no permission denied error. I uninstalled again in the same way, this time I went to the Market and installed Androidify. This is when things got interesting: (...)

So Androidify got my uid and my preferences now are belong to them. (...)

And we are screwed...

There is a bug report for this issue: http://code.google.com/p/android/issues/detail?id=14359

Google declined that bug because it actually is a bug caused by modifications done by the vendor for the device.

The authors of the App "Beautiful Widgets" gives its users the following advice:

** SAMSUNG GALAXY S & ANDROID 2.2 **
There is a bug in the Samsung Update which prevent to save the settings file. You need to factory reset your phone (...)

So this should help.

Please respond to this answer, if this happens to be the same issue on your Xoom device.

sulai
  • 5,204
  • 2
  • 29
  • 44
  • I'd go for a null key : see http://stackoverflow.com/questions/5368442/android-getsharedpreferences-error-map-value-without-name-attribute-boolean/19621603#19621603 – Mr_and_Mrs_D Oct 30 '13 at 15:54