I have an app making use of
SharedPreferences. One just stores app version to check against update for a changelog, the other contains some layout info that
clear() gets called on as the user chooses. I finally managed to get a
PreferenceFragment working and noticed a trend, so I thought I might ask this now before i go preference crazy (though I think I have enough).
I’ve done my best to search and see no specific mention of a problem, only that it’s possible to have multiples.
I’m a little concerned about
PreferenceManager.getDefaultSharedPreferences() grabbing the wrong pref, but I might simply be misunderstanding the usage.
The only relevant code i could think of from my activity:
SharedPreferences storedVer = getSharedPreferences(VER_NUM, 0); SharedPreferences savedLayout = getSharedPreferences(LAYOUT_SAVE, 0);
It is not bad practice at all. I think it is the opposite. I think different behaviours should use different
.getDefaultSharedPreferences() uses the default
com.company.packagename.xml file. And the others create their own files.
The followings advantages of using multiple
sharedPreference's come up in my mind.
- When you use BackupManager, you can provide which
sharedPreferencefiles to backup and restore.
- When the user logout, you can delete
sharedPreferencefile with that users private values in it. You may not want to delete some other.
From my experience with the
SharedPreferences I have noticed the following:
1) Always use try to make your
SharedPreference name and Attributes name unique all over the device.
2) Do not use the name of your
SharedPreference like “myPreference”, “preference”, “appPreference”…etc. Use your
PackageName as a unique identifier for the
SharedPreferences preferences = getSharedPreferences(Context.getPackageName(), Context.MODE_PRIVATE);
3) Use also a unique Keys for your attributes by concatenating the attribute name with the package name.
Editor editor = sharedpreferences.edit(); boolean isAdminKey = Context.getPackageName()+"admin"; editor.putString(isAdminKey , "value"); editor.commit();
4) No problem with editing multiple Keys values with one
MODE_PRIVATE when you create your preferences to prevent other applications from reading your
SharedPreferences. See step 2 for example
6) Do not rely on the
SharedPreferences 100% because it will be cleared if the user pressed
Clear Data button from the App info screen. Otherwise, create file in the
ExternalDirectory() or send your info to a server.
Late to the party but I would say do not use multiple preferences. Stick with
getDefaultSharedPreferences. I have seen many fail to keep track of the names of the saved preferences. In general it makes the code more complicated in just the wrong way (the compiler can’t help you manage your names). Moreover shared preferences are for a handful of small values – use the Filesystem for big things and a database for a lot of data.
I have seen the named shared preferences be used a lot and I believe this is an unfortunate trend spread by
Finally, your preference activities write to the default shared preferences – I have recently answered a question where this was the issue – would be completely avoided if default preferences were used. See: Android SharedPreferences not changing
You might consider wrapping the default shared preferences methods to make them even less verbose as I’ve done here