Android provides a number of options for persisting data, from using SQLite databases to internal or external storage on the SD card. For primitive types however, there is a much simpler technique for saving data between user sessions called SharedPreferences, which provides persistent key-value pairs of primitive data types.
A priori, we might think that, by only dealing with primitive data such as integers and strings, Shared Preferences is of limited use. However, resources in Android such as sounds or images are in fact assigned a unique integer id by the system. So android.content.SharedPreferences becomes a viable alternative to storing all kind of user preferences via settings screens, e.g. choosing a password as well as a default image or sound preference.
For example, here’s how to store a password entered by the user, using our application’s android.content.context :
// label identifying our application preferences String PREFS_NAME = "OurPrefs"; SharedPreferences settings = context.getSharedPreferences(PREFS_NAME, Context.MODE_PRIVATE); SharedPreferences.Editor editor = settings.edit(); editor.putString("passkey", passwsord); editor.commit();
Context.MODE_PRIVATE is the default file preferences creation mode, which restricts the access of those preferences to our application only. There are two other more ‘liberal’ modes, MODE_WORLD_READABLE and MODE_WORLD_WRITABLE, which are pretty much self-explanatory. The password is persisted using the SharedPreferences.Editor. And here’s how to retrieve it later during another run of the application:
SharedPreferences settings = context.getSharedPreferences(PREFS_NAME, Context.MODE_PRIVATE); String password = settings.getString("passkey", "");
For saving a chosen sound by the user via a settings screen, say a sound called “ping” among others stored in a “raw” sub-solder of our Android resources folder, it works pretty much the same way, except that this time we’re using an integer id instead of a String type:
SharedPreferences settings = context.getSharedPreferences(PREFS_NAME, Context.MODE_PRIVATE); SharedPreferences.Editor editor = settings.edit(); editor.putInt("soundkey", R.id.ping); editor.commit();
And retrieving the sound preference:
SharedPreferences settings = context.getSharedPreferences(PREFS_NAME, Context.MODE_PRIVATE); int soundID = settings.getInt("soundkey", 0);
Simple enough. The above code snippets can be used directly inside Activities using their Context object, but a probably better way would be to encapsulate all the persistence and retrieval logic in a Preferences utility class. There is even a more standard way for saving further detailed user preferences: the PreferenceActivity, which comes out-of-the-box and uses SharedPreferences automatically to persist user data across application runs.
Using SharedPreferences is ideal for simple use cases where a database, file system or even a PreferenceActivity would be overkill. As for limitations, apart from the fact that we can only store primitive types, here’s another one mentioned in the API docs:
Note: currently this class does not support use across multiple processes. This will be added later.
So, as the man says, if our application uses more than one Android process, we won’t be able to use SharedPreferences. We’ll have to try again later.