The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.
Android has many different ways for you to store data for long-term use by your
activity. The simplest ones to use are
SharedPreferences and simple files.
Android allows activities and applications to keep preferences, in the form of
key/value pairs (akin to a
Map), that will hang around between invocations of
an activity. As the name suggests, the primary purpose is for you to store
user-specified configuration details, such as the last feed the user looked at
in your feed reader, or what sort order to use by default on a list, or
whatever. Of course, you can store in the preferences whatever you like, so
long as it is keyed by a
String and has a primitive value (
Preferences can either be for a single activity or shared among all activities in an application. Other components, such as services, also can work with shared preferences.
To get access to the preferences, you have three APIs to choose from:
getPreferences()from within your
Activity, to access activity-specific preferences
getSharedPreferences()from within your
Activity(or other application
Context), to access application-level preferences
PreferenceManager, to get the shared preferences that work in concert with Android’s overall preference framework
The first two take a security mode parameter. The right answer here is
MODE_PRIVATE, so no other applications can access the file. The
getSharedPreferences() method also takes a name of a set of preferences;
getPreferences() effectively calls
getSharedPreferences() with the
activity’s class name as the preference set name. The
getDefaultSharedPreferences() method takes the
Context for the preferences
All of those methods return an instance of
SharedPreferences, which offers a
series of getters to access named preferences, returning a suitably-typed
getBoolean() to return a boolean preference). The getters also
take a default value, which is returned if there is no preference set under the
Unless you have a good reason to do otherwise, you are best served using the
third option above —
getDefaultSharedPreferences() — as that will give
SharedPreferences object that works with a
default, as will be described later in this chapter.
Given the appropriate
SharedPreferences object, you can use
edit() to get
an “editor” for the preferences. This object has a set of setters that mirror
the getters on the parent
SharedPreferences object. It also has:
remove()to get rid of a single named preference
clear()to get rid of all preferences
commit()to persist your changes made via the editor
The last one is important — if you modify preferences via the editor and
fail to save the changes, those changes will evaporate once the editor
goes out of scope.
commit() is a blocking call, while
asynchronously. Ideally, use
apply() where possible, though it was only
added in Android 2.3, so it may not be available to you if you are aiming to
support earlier versions of Android than that.
Conversely, since the preferences object supports live changes, if one part of your application (say, an activity) modifies shared preferences, another part of your application (say, a service) will have access to the changed value immediately.
The preview of this section is unavailable right now, but if you leave your name and number at the sound of the tone, it might get back to you (BEEEEEEEEEEEEP!).
The preview of this section was the victim of a MITM ('Martian in the middle') attack.
The preview of this section will not appear here for a while, due to a time machine mishap.