java – Android – Is it bad practice to have multiple Shared Preferences?-ThrowExceptions

Exception or error:

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);
How to solve:

It is not bad practice at all. I think it is the opposite. I think different behaviours should use different sharedPreference files.

.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 sharedPreference files to backup and restore.
  • When the user logout, you can delete sharedPreference file 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 SharedPreference name.

Example:

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.

Example:

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 commit().

5) Use 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 copyPaste().

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

Leave a Reply

Your email address will not be published. Required fields are marked *