Ditch the Boilerplate: The Kotlin Delegation Trick to Tame Android's SharedPreferences

 Tame Android’s SharedPreferences with Elegant, Type-Safe Properties

The Kotlin Delegation Trick to Tame Android's SharedPreferences

If you’re an Android developer working in Kotlin, you’re likely familiar with the dreaded boilerplate that comes with managing simple settings using SharedPreferences.

Every time you need to persist a boolean or retrieve a string, you write variations of:

// The old, verbose way
val editor = prefs.edit()
editor.putBoolean("IS_ENABLED", true)
editor.apply()

// ... Later ...
val isEnabled = prefs.getBoolean("IS_ENABLED", false)

It’s functional, but it’s repetitive, error-prone (typos in keys!), and certainly not elegant.

What if you could treat your persisted settings just like regular Kotlin properties, with full type safety and zero extra functions?

This is where Kotlin Property Delegation steps in, transforming a noisy settings repository into a clean, concise, and highly readable class.

The Power of by: Understanding Delegation

In Kotlin, the by keyword allows a class property to hand off its getter and setter logic to a separate object, the delegate.

When you declare:

var isLoaded by someDelegate
  • Reading isLoaded calls a special getValue function on someDelegate.
  • Writing to isLoaded calls a special setValue function on someDelegate.

To make SharedPreferences our delegate, we just need to implement these two operator functions and have them handle the actual disk I/O.

The Elegant and Enhanced Solution (with a Factory)

To ensure we maintain type safety and configurability (allowing custom keys and defaults), we’ll implement the delegate using a private factory method.

This approach is the cleanest, most scalable way to implement the feature.

Step 1: The Delegate Factory and Builders

We need two essential imports: kotlin.reflect.KProperty to access the property name, and the crucial ReadWriteProperty interface.

// SettingsDelegates.kt

import android.content.SharedPreferences
import android.content.SharedPreferences.Editor
import kotlin.reflect.KProperty
import kotlin.properties.ReadWriteProperty // ⬅️ FIX: Missing Import Added

// 1. Extension property for better discoverability
val SharedPreferences.delegates: PreferenceDelegates
    get() = PreferenceDelegates(this) // NOTE: Creates a new object on each access, which is fine for simple usage.

class PreferenceDelegates(private val prefs: SharedPreferences) {

    // --- Delegate Functions (exposed to the user) ---

    fun boolean(default: Boolean = false, key: String? = null) = create(
        default = default,
        key = key, // ⬅️ FIX: key parameter passed
        getter = { k, d -> prefs.getBoolean(k, d) },
        setter = { k, v -> prefs.edit().putBoolean(k, v) }
    )

    fun string(default: String, key: String? = null) = create(
        default = default,
        key = key, // ⬅️ FIX: key parameter passed
        getter = { k, d -> prefs.getString(k, d) ?: d },
        setter = { k, v -> prefs.edit().putString(k, v) }
    )
    
    // ⬅️ FIX: long() delegate implemented
    fun long(default: Long = 0L, key: String? = null) = create(
        default = default,
        key = key, // ⬅️ FIX: key parameter passed
        getter = { k, d -> prefs.getLong(k, d) },
        setter = { k, v -> prefs.edit().putLong(k, v) }
    )

    // --- Private Factory Function (The engine) ---

    // ⬅️ FIX: key parameter added to factory function signature
    private fun <T> create(
        default: T,
        key: String?,
        getter: (key: String, default: T) -> T,
        setter: (key: String, value: T) -> Editor,
    ) = object : ReadWriteProperty<Any?, T> { // Implementation object

        // Helper to determine the key: use provided key or the property name
        private fun getKey(property: KProperty<*>) = key ?: property.name

        override fun getValue(thisRef: Any?, property: KProperty<*>): T {
            // Read: Delegate the call to the type-specific getter lambda
            return getter(getKey(property), default)
        }

        override fun setValue(thisRef: Any?, property: KProperty<*>, value: T) {
            // Write: Delegate the call to the type-specific setter lambda and apply change
            setter(getKey(property), value).apply() 
        }
    }
}

Step 2: Usage is Beautifully Simple

Now, the settings class is clean, readable, and highly maintainable.

// ExampleUsage.kt

class AppSettings(context: Context) {
    
    // Get the standard SharedPreferences instance
    private val prefs = context.getSharedPreferences("app_settings", Context.MODE_PRIVATE)

    /**
     * Setting with an explicit key for safe refactoring.
     */
    var isBetaTester: Boolean by prefs.delegates.boolean(
        default = false, 
        key = "PREF_BETA_TESTER" // The key stored on disk
    )

    /**
     * Setting using the property name ("currentThemeId") as the key.
     */
    var currentThemeId: String by prefs.delegates.string(
        default = "light_theme" 
    )
    
    /**
     * FIX: The implemented long() delegate is now correctly used.
     */
    var sessionTimeoutMillis: Long by prefs.delegates.long(5000L)
    
    // --- Accessing the settings ---
    fun toggleBeta() {
        isBetaTester = !isBetaTester // Clean read/write access
    }
}

Performance & Modern Nuance

While this pattern is elegant, it’s vital to use it judiciously.

The “Chatty” Interface (Refined Wording)

The key to SharedPreferences performance is understanding where the data lives:

  • Reads (getValue): When you read a delegated property, the value is served directly from an in-memory map maintained by the Android system. This is very fast.
  • Writes (setValue): When you write, the changes are written to the in-memory map instantly and then written to disk asynchronously using apply().

My Recommendation: Use this delegation for simple, global settings. For large, structured, or transaction-heavy data, the overhead of constant memory and asynchronous disk updates is too high. You should use dedicated databases like Room.

Modern Android Alternative

For a 2025 development context, it’s important to note:

Jetpack DataStore is now the recommended replacement for SharedPreferences in new applications.

DataStore offers better thread safety and works with Kotlin Flows for reactive data, making it a superior choice for many projects. However, the delegation pattern presented here remains:

  • A perfectly valid and clean solution for existing projects using SharedPreferences.
  • An excellent way to learn and practice powerful Kotlin property delegation concepts.

Frequently Asked Questions (FAQs)

Why explicitly provide a key when the property name works?

Using the property name (property.name) as the key works by default. However, explicitly providing a key (e.g., "PREF_BETA_TESTER") makes refactoring safer. If you rename the property from isBetaTester to isEarlyAccess, the key stored on disk remains the same, preventing users from losing their setting.

Can I use commit() instead of apply()?

Yes, you can, but the delegate uses apply() by default because it performs the disk write asynchronously, preventing UI thread blocking. Using commit() makes the write synchronous, which should only be used if you must guarantee the write completed before launching another component (e.g., a critical safety check before quitting the app).

Does this support custom objects (like a user profile)?

Not directly with the basic delegates. The standard SharedPreferences API only supports primitives and strings. To store custom objects or lists, you would need to use a single string() delegate and handle the object's serialization (converting it to a JSON string using Gson/Moshi) within the delegate's getValue and setValue logic.

Is the creation of the PreferenceDelegates object a concern?

The extension property:

val SharedPreferences.delegates: PreferenceDelegates get() = PreferenceDelegates(this)

creates a new PreferenceDelegates instance every time you access it. This is usually not a problem because you only access it once during the initialization of your AppSettings class. It's safe and idiomatic.

Conclusion

By applying Kotlin’s property delegation, we’ve transformed the tedious I/O of SharedPreferences into a beautiful, type-safe, and highly readable API. You gain maintainability and compile-time safety—all using features baked right into the Kotlin language.

To the reader: What is the most verbose piece of Android boilerplate you’ve successfully eliminated using a Kotlin feature like delegation or extension functions? Share your favorite trick in the comments!

If you find my content useful, feel free to support my work here. Every contribution is greatly appreciated! 🙏

Comments

Post a Comment

Popular posts from this blog

Stop Writing Massive when Statements: Master the State Pattern in Kotlin

Image
 Tame Your Codebase with Elegant, Scalable, and Type-Safe State Machines Do you manage complex objects that change their behavior dramatically based on their internal status? If so, you’ve likely battled a common foe: the sprawling  when  statement that haunts every method in your class. It looks something like this: fun handleAction () { when (state) { State.A -> { /* logic for A */ } State.B -> { /* logic for B */ } State.C -> { /* logic for C */ } // ... and the list keeps growing! } } Every time you add a new state (e.g.,  State.D ), you have to hunt down and update  every single function  with a new case. This is a maintenance nightmare, a direct violation of the  Open/Closed Principle  (OCP), and a major code smell. Your logic is scattered by  action  when it should be grouped by  state . The solution? The  State Pattern . And with modern Kotlin, we can implement it w...
Read more

Coroutines & Flows: 5 Critical Anti-Patterns That Are Secretly Slowing Down Your Android App

Image
 Stop sneaky performance killers. Spot and fix Kotlin issues that cause crashes, memory leaks, and laggy UIs. Coroutines and Kotlin Flows are the bedrock of modern asynchronous programming on Android. They allow us to write clean, sequential-looking code that manages complex background operations, network calls, and database transactions. But power comes with responsibility. Many developers, despite using Coroutines daily, unknowingly introduce subtle mistakes —  anti-patterns  — that lead to memory leaks, silent crashes, data loss, and UI jank. Based on insights from top-tier Android development, here are five critical Coroutine and Flow anti-patterns you must identify and fix today, plus one bonus pitfall I often see in code reviews. 1. The Main Thread Trap: Heavy Work in  viewModelScope When you launch a coroutine inside a  ViewModel  using  viewModelScope.launch { ... } , where do you think that work runs by default? The  Main Thread ! If your...
Read more

Code Generation vs. Reflection: A Build-Time Reliability Analysis

Image
 Choose compile-time safety over runtime simplicity to ensure better R8 optimization, avoid reflection issues, and cut production crashes. The world of Android development offers numerous ways to achieve the same goal, but not all paths are created equal. When it comes to tasks like dependency injection, JSON parsing, or database interaction, two prominent approaches stand out: Code Generation and Reflection. While reflection might seem appealing for its initial simplicity, a deeper dive reveals that   Code Generation offers superior build-time reliability and R8 compatibility , making it the more robust choice for production-ready applications. The Allure of Reflection: Simplicity at a Cost Reflection, at its core, allows a program to inspect and modify its own structure and behavior at runtime. This dynamic nature can be incredibly powerful, enabling libraries to work with classes and their members without needing to know them at compile time. Example: A (simplified) Reflect...
Read more