Android Development
SharedPreferences
getDefaultSharedPreferences
getSharedPreferences
Android App Development

Difference between getDefaultSharedPreferences and getSharedPreferences

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

Android gives you two common ways to open SharedPreferences, and they solve slightly different problems. PreferenceManager.getDefaultSharedPreferences(context) opens one conventional app-wide preferences file, while context.getSharedPreferences(name, mode) lets you choose the file name yourself.

What getDefaultSharedPreferences() is for

getDefaultSharedPreferences() is the convenience option. It returns the default preferences file that Android and older preference-screen APIs commonly expect.

In Kotlin, that looks like this:

kotlin
val prefs = PreferenceManager.getDefaultSharedPreferences(context)
val darkMode = prefs.getBoolean("dark_mode", false)

The advantage is consistency. If your app has one central set of settings, every screen can read and write the same file without repeating a file name constant everywhere.

This method is especially common in older Android examples that use framework preference screens, because those APIs often assume the default preferences file.

What getSharedPreferences(name, mode) is for

getSharedPreferences() is the explicit version. You provide the file name, so you can split data into multiple files when that makes the design clearer.

kotlin
1val sessionPrefs = context.getSharedPreferences(
2    "session_cache",
3    Context.MODE_PRIVATE
4)
5
6sessionPrefs.edit()
7    .putString("last_user_id", "42")
8    .apply()

This is useful if you want to separate user-visible settings from other small persistent data such as cached metadata, onboarding state, or feature flags.

On modern Android, the mode is almost always Context.MODE_PRIVATE.

The main difference is which file gets opened

After you obtain the SharedPreferences object, the API is the same either way. You still call getString, getBoolean, edit, apply, and commit.

So the important difference is not the read and write syntax. It is the underlying file choice:

  • 'getDefaultSharedPreferences() means "use the standard default preferences file"'
  • 'getSharedPreferences(name, mode) means "use this exact named file"'

That distinction matters the moment you have more than one preferences file in the app.

Example: default settings versus feature-specific storage

Here is a concrete comparison:

kotlin
1val defaultPrefs = PreferenceManager.getDefaultSharedPreferences(context)
2defaultPrefs.edit()
3    .putBoolean("notifications_enabled", true)
4    .apply()
5
6val analyticsPrefs = context.getSharedPreferences(
7    "analytics_prefs",
8    Context.MODE_PRIVATE
9)
10analyticsPrefs.edit()
11    .putLong("last_upload_time", 1710000000L)
12    .apply()

The first value goes into the app's default settings file. The second value goes into a different named file. If you write with one and read with the other, the key will seem to "disappear" because you are looking in a different store.

When to use each approach

Use getDefaultSharedPreferences() when the app has one obvious bucket of shared settings and you want a simple convention.

Use getSharedPreferences(name, mode) when:

  • you want multiple files with clear boundaries
  • you need a stable custom name for migration or debugging
  • you want to keep non-settings data out of the main settings store

The default API is about convenience. The named API is about explicit control.

A modern note about DataStore

For new Android projects, Jetpack DataStore is often recommended over SharedPreferences because it handles asynchronous I/O more cleanly and offers better structure. That does not change the answer here, but it matters if you are designing fresh persistence code rather than maintaining existing app settings logic.

Common Pitfalls

  • Assuming getDefaultSharedPreferences() and getSharedPreferences() refer to the same file.
  • Writing a key to the default file and trying to read it from a custom-named file.
  • Creating many preference files without a clear reason, which makes app state harder to track.
  • Storing large or relational data in SharedPreferences instead of a database or file.
  • Ignoring DataStore when starting new Android persistence work.

Summary

  • 'getDefaultSharedPreferences() opens the app's conventional default preferences file.'
  • 'getSharedPreferences(name, mode) opens a specific named preferences file.'
  • Both return the same SharedPreferences interface once the file is opened.
  • The real difference is file selection and organization, not the read or write methods.
  • Use the default file for app-wide settings and named files when you need explicit separation.

Course illustration
Course illustration

All Rights Reserved.