Android Data, Networking & APIs

Storing Data with SharedPreferences

18 min Lesson 1 of 12

Storing Data with SharedPreferences

Almost every Android app needs to remember something between sessions: whether the user has completed onboarding, their chosen theme, an authentication token, or the last search query they typed. SharedPreferences is Android's built-in key-value store for exactly this kind of lightweight, persistent data. It stores primitive types and strings in an XML file on the device's internal storage, survives process death and device reboots, and requires zero setup code.

What SharedPreferences Is (and Is Not)

Think of SharedPreferences as a typed map that is automatically flushed to disk. It supports six value types: String, int, long, float, boolean, and Set<String>. That is its entire scope. It is not a relational database, not a file store, and not a good fit for large or structured data. If you need to store more than a few dozen key-value pairs, or if the data has relationships, use Room instead (covered in Lesson 3).

Where the data lives: Each preferences file is stored at /data/data/<your.package.name>/shared_prefs/<filename>.xml. It is private to your app — other apps cannot read it. The file is not encrypted by default, so never store passwords or sensitive tokens here without additional protection.

Getting a SharedPreferences Instance

There are two ways to obtain a SharedPreferences object. The first is getSharedPreferences(name, mode), which lets you name the file. The second is getPreferences(mode), available only inside an Activity, which uses the activity's class name as the file name.

// In an Activity or Context subclass
SharedPreferences prefs = getSharedPreferences("user_settings", Context.MODE_PRIVATE);

// Inside an Activity only — uses the Activity class name as the file name
SharedPreferences activityPrefs = getPreferences(Context.MODE_PRIVATE);

Always pass Context.MODE_PRIVATE as the mode. The other modes (MODE_WORLD_READABLE, MODE_WORLD_WRITEABLE) were deprecated in API 17 and removed in API 24 because they are security vulnerabilities. MODE_PRIVATE is the only safe choice.

Reading Values

Every get method on SharedPreferences takes a key and a default value that is returned when the key does not exist. Always supply a sensible default — it removes the need for null checks and makes the intent of the code clear.

SharedPreferences prefs = getSharedPreferences("user_settings", Context.MODE_PRIVATE);

String username  = prefs.getString("username", "Guest");
int    launchCount = prefs.getInt("launch_count", 0);
boolean darkMode = prefs.getBoolean("dark_mode", false);
float  textScale = prefs.getFloat("text_scale", 1.0f);

// Check whether a key is present at all
boolean hasToken = prefs.contains("auth_token");

Writing Values with Editor

You cannot write directly through a SharedPreferences object. Instead you open an Editor, make your changes, and then commit them. This transactional design means either all your changes land on disk or none of them do.

SharedPreferences prefs = getSharedPreferences("user_settings", Context.MODE_PRIVATE);
SharedPreferences.Editor editor = prefs.edit();

editor.putString("username", "edrees");
editor.putInt("launch_count", launchCount + 1);
editor.putBoolean("dark_mode", true);
editor.putFloat("text_scale", 1.2f);

editor.apply(); // asynchronous — preferred
// editor.commit(); // synchronous — avoid on the main thread

apply() vs commit(): apply() writes to an in-memory cache immediately and schedules the disk write on a background thread. commit() blocks the calling thread until the disk write completes and returns a boolean indicating success. Use apply() on the main thread (which is the vast majority of cases). Use commit() only when you genuinely need confirmation that the data reached disk before continuing — for example, just before the process might be killed in a critical operation.

You can also chain editor calls using the fluent API:

getSharedPreferences("user_settings", Context.MODE_PRIVATE)
    .edit()
    .putString("username", "edrees")
    .putInt("launch_count", 1)
    .putBoolean("onboarding_complete", true)
    .apply();

Removing and Clearing Data

SharedPreferences.Editor editor = prefs.edit();

editor.remove("auth_token");   // remove a single key
editor.clear();                // wipe the entire file
editor.apply();

Listening for Changes

Your UI sometimes needs to react when a preference changes — for example, switching between light and dark theme. Register an OnSharedPreferenceChangeListener and unregister it when the component is destroyed to avoid memory leaks.

public class SettingsActivity extends AppCompatActivity
        implements SharedPreferences.OnSharedPreferenceChangeListener {

    private SharedPreferences prefs;

    @Override
    protected void onResume() {
        super.onResume();
        prefs = getSharedPreferences("user_settings", Context.MODE_PRIVATE);
        prefs.registerOnSharedPreferenceChangeListener(this);
    }

    @Override
    protected void onPause() {
        super.onPause();
        prefs.unregisterOnSharedPreferenceChangeListener(this);
    }

    @Override
    public void onSharedPreferenceChanged(SharedPreferences sharedPreferences, String key) {
        if ("dark_mode".equals(key)) {
            boolean dark = sharedPreferences.getBoolean(key, false);
            applyTheme(dark);
        }
    }

    private void applyTheme(boolean dark) {
        // recreate() or delegate to AppCompatDelegate
    }
}

Hold the listener in a strong reference. SharedPreferences stores listeners in a WeakHashMap. If you pass an anonymous lambda or a local variable, it may be garbage-collected almost immediately and your listener will silently stop firing. Always store the listener as an instance field or implement the interface on the Activity/Fragment class directly, as shown above.

A Practical Pattern: Preferences Helper Class

Spreading magic string keys across multiple classes is a maintenance hazard. Centralise all preference access in a dedicated helper so keys are defined once and callers never see raw strings.

public class UserPreferences {

    private static final String PREFS_NAME    = "user_settings";
    private static final String KEY_USERNAME  = "username";
    private static final String KEY_DARK_MODE = "dark_mode";
    private static final String KEY_LAUNCHES  = "launch_count";

    private final SharedPreferences prefs;

    public UserPreferences(Context context) {
        // Use application context to avoid leaking an Activity
        prefs = context.getApplicationContext()
                       .getSharedPreferences(PREFS_NAME, Context.MODE_PRIVATE);
    }

    public String getUsername()           { return prefs.getString(KEY_USERNAME, "Guest"); }
    public void   setUsername(String name){ prefs.edit().putString(KEY_USERNAME, name).apply(); }

    public boolean isDarkMode()           { return prefs.getBoolean(KEY_DARK_MODE, false); }
    public void    setDarkMode(boolean on){ prefs.edit().putBoolean(KEY_DARK_MODE, on).apply(); }

    public int  getLaunchCount()          { return prefs.getInt(KEY_LAUNCHES, 0); }
    public void incrementLaunchCount()    {
        prefs.edit().putInt(KEY_LAUNCHES, getLaunchCount() + 1).apply();
    }
}

Callers only interact with well-typed methods and never know about the underlying string keys.

When to Use SharedPreferences

User preferences — theme, language, notification settings.
Session flags — has the user seen the onboarding screen, is the user logged in.
Simple cached values — the last known city for a weather app, the last selected tab.
Small app-state snippets — a user ID string, a preference integer.

Do not use it for: large datasets, lists of objects, binary data, or anything that benefits from querying. For those cases, Room is the right tool.

Summary

SharedPreferences provides a simple, durable key-value store backed by an XML file. Obtain an instance with getSharedPreferences("name", Context.MODE_PRIVATE), read values with typed get methods that accept defaults, and write through an Editor finished with apply(). Keep string keys out of callers by wrapping the preferences in a dedicated helper class. In the next lesson you will move to SQLite for data that needs structure and queryability.