Amol Pawar

Let’s talk about something that trips up a lot of Android developers — especially when building apps with complex navigation: the Android Back Stack.

You know that moment when you hit the back button and your app behaves like it has a mind of its own? Yeah, we’ve all been there. The Android Back Stack can be tricky, but once you get a handle on it, your app’s navigation feels intuitive, snappy, and exactly how users expect it to behave.

This guide breaks it down step by step, with real-world code examples, clear explanations, and some personal tips from my own development experience.

What Is the Android Back Stack, Really?

The Android Back Stack is just a managed stack (think: a vertical pile) of activities or fragments that tracks the user’s navigation history. When the user presses the back button, Android pops the top of the stack and returns to the previous screen.

Simple in theory. In practice? It gets more interesting.

Let’s start with an example.

Activities and the Back Stack

When you start a new activity using:

val intent = Intent(this, SecondActivity::class.java)
startActivity(intent)

Android pushes SecondActivity onto the back stack. Now, pressing the back button pops it off and returns you to MainActivity.

So far, so good.

By default, each call to startActivity() adds the new activity to the task’s back stack, unless you explicitly modify this behavior using intent flags or manifest attributes.

Customizing Back Stack Behavior with Intent Flags

You can tweak the back stack behavior with intent flags. Here are a few you’ll use often:

1. FLAG_ACTIVITY_CLEAR_TOP

Let’s say your stack looks like this: A → B → C → D

If you call startActivity() from D to go back to B with FLAG_ACTIVITY_CLEAR_TOP, Android will pop off C and D and bring B to the top.

val intent = Intent(this, B::class.java)
intent.flags = Intent.FLAG_ACTIVITY_CLEAR_TOP
startActivity(intent)

It’s like saying: “Hey Android, I want B on top again — clear anything above it.”

2. FLAG_ACTIVITY_NEW_TASK

This one creates a new task entirely. It’s mostly used in system-level or launcher-related contexts.

val intent = Intent(this, MainActivity::class.java)
intent.flags = Intent.FLAG_ACTIVITY_NEW_TASK
startActivity(intent)

3. FLAG_ACTIVITY_SINGLE_TOP

If the activity you’re trying to start is already at the top of the stack, don’t create a new instance — just reuse the existing one.

val intent = Intent(this, ProfileActivity::class.java)
intent.flags = Intent.FLAG_ACTIVITY_SINGLE_TOP
startActivity(intent)

You’ll also need to handle this in onNewIntent() in the target activity.

Fragments and the Back Stack: The Modern Way

These days, many apps use fragments instead of spinning up new activities. That’s where things get more nuanced.

When using fragments, you manage the back stack yourself with FragmentManager. Here’s how you can add a fragment to the back stack:

supportFragmentManager.beginTransaction()
    .replace(R.id.fragment_container, SecondFragment())
    .addToBackStack(null)
    .commit()

Calling addToBackStack() (with either null or a string tag) adds the fragment transaction to the back stack, which means the system will remember it and can reverse the transaction—i.e., remove the newly added fragment and restore the previous one—when the back button is pressed.

If addToBackStack() is not called, the transaction is not saved to the back stack, so pressing the back button does not reverse that specific transaction.

In that case, if there are no other entries in the back stack and no other UI elements to pop, pressing the back button will exit the activity (if you’re at the top of the stack).

Pro Tip: Naming Your Back Stack Entries

You can pass a string tag to addToBackStack("tag_name") to track what’s on the stack. This helps with debugging or popping specific entries.

.addToBackStack("SecondFragment")

Then later:

supportFragmentManager.popBackStack("SecondFragment", 0)

You now have surgical control over your navigation history.

Jetpack Navigation Component: A Modern Solution

If you’re using the Jetpack Navigation Component (and you probably should be), it abstracts much of this back stack management while still giving you hooks when needed.

findNavController().navigate(R.id.action_home_to_detail)

And to go back:

findNavController().popBackStack()

The Navigation Component maintains a back stack internally and works seamlessly with the system back button and deep links. It also integrates nicely with BottomNavigationView, DrawerLayout, and more.

Common Mistakes and How to Avoid Them

Here are a few Android Back Stack missteps I’ve seen:

Mistake #1: Forgetting addToBackStack()

If you don’t add your fragment transaction to the back stack, pressing back won’t return to the previous fragment — it might just exit the app.

Mistake #2: Overusing Activities

Switching activities too often can make your app feel clunky. Stick to fragments when screens are tightly related.

Mistake #3: Ignoring Task Affinities

Sometimes, your app can get into weird states when launched from a notification or deep link. Always check if your task and back stack behave as expected.

Handling the System Back Button

You can override the back button behavior in both activities and fragments:

In an activity:

override fun onBackPressed() {
    // Custom logic
    super.onBackPressed()
}

In a fragment (Jetpack way):

requireActivity().onBackPressedDispatcher.addCallback(viewLifecycleOwner) {
    // Your custom back logic here
}

This gives you full control while still respecting Android’s expected navigation model.

Conclusion

A smooth, predictable back navigation experience is one of the most critical parts of mobile UX. Users expect it to “just work.”

Understanding how the Android Back Stack works — and how to tame it — gives you a major edge as a developer. Whether you’re working with activities, fragments, or the Navigation Component, mastering this system ensures your app feels polished and professional.

You build a clean UI, test it on your emulator, and everything looks solid. But once QA or users get their hands on it, layout bugs pop up — text overflowing, views misaligned, odd paddings. It happens more often than we like to admit.

That’s where the Paparazzi Testing Library proves its worth. It’s a powerful snapshot testing tool that helps you catch UI issues early — without spinning up an emulator or device. It’s fast, reliable, and runs directly on the JVM.

Here’s what makes Paparazzi a smart addition to your toolkit — and how to get started using it today.

What Is the Paparazzi Testing Library?

The Paparazzi Testing Library is a screenshot testing tool developed by Cash App (Square). It renders Android views directly on your local JVM, meaning no more waiting for Gradle to launch an emulator. You write tests that take UI snapshots and compare them to previously approved images. If something changes, you’ll know — instantly.

It’s like version control for your UI.

Why Snapshot Testing Matters

Snapshot testing is about locking down the visual representation of your UI. When your layout changes unexpectedly — due to a rogue commit, a bumped font size, or some sneaky theme refactor — snapshot tests fail, and you get a diff of what changed.

This catches visual regressions without needing a manual check.

“But isn’t this what Espresso is for?”

Nope. Espresso is great for behavior tests — clicks, scrolls, text input — but it’s not built to capture static snapshots or catch pixel-level layout issues. That’s exactly what Paparazzi is made for.

In essence:

• Espresso = “Does the app behave correctly when a user interacts with it?”
• Paparazzi = “Does the app look correct across different states and configurations?”

They complement each other, addressing different aspects of UI testing.

Getting Started with Paparazzi

First, you need to add the dependency to your build.gradle.kts:

// build.gradle.kts (module)
dependencies {
    testImplementation("app.cash.paparazzi:paparazzi:1.3.0")
}

Then, make sure your project uses AGP 7.0+. Paparazzi integrates seamlessly with Compose and traditional XML views.

Your First Snapshot Test

Let’s say you have a simple composable:

@Composable
fun GreetingCard(name: String) {
    Surface(color = Color.White) {
        Text(
            text = "Hello, $name..!",
            modifier = Modifier.padding(16.dp),
            fontSize = 18.sp
        )
    }
}

Here’s how you’d test it with Paparazzi:

class GreetingCardTest {

@get:Rule
    val paparazzi = Paparazzi()
    @Test
    fun greetingCardSnapshot() {
        paparazzi.snapshot {
            GreetingCard(name = "Shakuntala Devi")
        }
    }
}

Run the test, and boom — you get a PNG snapshot of the rendered composable. If you change the layout later and rerun the test, Paparazzi compares the new image to the baseline. Any difference? You’ll get a visual diff and a failing test.

Reviewing Changes

Let’s say your team modifies the GreetingCard to bump the padding. When you commit, the snapshot test will fail (as expected). Here’s the best part: Paparazzi gives you a side-by-side diff view of the change.

If the change is intentional, just approve the new snapshot. If not, you just caught a bug before it shipped.

Tips and Best Practices

Here are a few lessons I’ve learned the hard way:

• Use stable fonts and themes: Dynamic styling can trigger unnecessary diffs.
• Avoid timestamps or dynamic content in your snapshots.
• Organize snapshots by feature to keep your test suite tidy.
• Pair with pull requests: Have your CI pipeline run snapshot tests on every PR.

How It Works Under the Hood

Paparazzi uses RenderScript and Skia to render Android views headlessly. It builds your composables or views in a JVM environment and captures the exact pixels they produce. 

No emulator, no instrumentation, no flakiness.

When Not to Use Paparazzi

Paparazzi is not meant to test animations, gestures, or interactive flows. It shines in static UI verification. If your test involves user interaction, Espresso or Compose UI testing is your better bet.

Conclusion

If you’re serious about UI quality, the Paparazzi Testing Library is a must-have. It’s fast, consistent, and ridiculously easy to use once you get the hang of it. Plus, catching layout regressions early saves your team countless hours of QA churn and bug fixes.

Give it a try on your next UI feature. You’ll wonder how you ever lived without it.

TL;DR

• Paparazzi = snapshot testing for Android UIs on the JVM
• No emulator needed
• Great for catching unexpected layout changes
• Easy to set up and integrates with Compose
• Ideal for static UI components

When building Android apps, it’s easy to focus only on the code, UI, and features. But behind every successful app lies a set of powerful, low-level tools that keep the whole process moving. These are the Android SDK Tools — the unsung heroes of the Android development ecosystem.

In this post, we’ll break down what they are, how they work, and why every Android developer should understand them — even in the age of Android Studio.

What Are Android SDK Tools?

Android SDK Tools are a collection of command-line utilities that help you build, test, and debug Android apps. They used to be packaged together as “SDK Tools,” but over time, they’ve been split into modular components like:

• platform-tools — includes ADB, fastboot, and other core tools.
• build-tools — includes utilities like aapt, zipalign, etc.

Even though Android Studio handles much of this behind the scenes, these tools are still critical — especially when things go wrong, or when you want to automate development tasks.

Essential SDK Tools Every Android Developer Should Know

Let’s take a closer look at the key tools that power Android development under the hood:

1. ADB (Android Debug Bridge)

ADB is a command-line tool that lets your computer communicate with an Android device or emulator.

Think of it as a remote control for your Android environment. You can install apps, copy files, debug logs, and even run shell commands directly on the device.

Common ADB Commands:

adb devices             # Lists connected devices
adb install myapp.apk   # Installs an APK
adb logcat              # Displays real-time device logs

This is one of the most valuable tools in your toolbox, especially for real-time debugging.

2. fastboot

When your device is in bootloader mode, fastboot lets you flash images to the device, unlock the bootloader, and perform other low-level operations.

It’s typically used for:

• Flashing custom recoveries or ROMs
• Unlocking or locking bootloaders
• Recovering bricked devices

While not every developer uses fastboot regularly, it’s indispensable for anyone working near the hardware layer or with custom builds.

3. R8 and ProGuard

Originally, ProGuard was used to shrink and obfuscate Java code in Android apps. Today, R8 has replaced it as the default tool for most modern Android projects.

R8 performs:

• Code shrinking
• Dead code elimination
• Resource optimization
• Obfuscation (to make reverse engineering harder)

R8 is built into the Android Gradle plugin, so you don’t typically run it manually — but understanding what it does can help you configure it properly in proguard-rules.pro.

Why These Tools Still Matter in 2025

Even though Android Studio and Gradle handle most of the heavy lifting today, knowing how SDK tools work gives you:

• More control over your builds and deployments
• Better debugging capabilities, especially on real devices
• The ability to automate testing, CI/CD, and device management
• Deeper insights into how Android actually works

When something breaks outside the Studio UI, these tools are often your first (and best) line of defense.

Conclusion

The Android SDK Tools may not be glamorous, but they are the engine under the hood of Android development. Whether you’re pushing your first APK or debugging a complex issue, understanding ADB, fastboot, and R8 will make you a more capable — and confident — developer.

If you’re tired of repeating the same dependencies across different modules in your Android project, you’re not alone. Managing dependencies manually is error-prone, messy, and not scalable. Fortunately, Bundles in libs.versions.toml offer a clean and modern solution that saves time and reduces duplication. Let’s break it down, step by step, in a simple way.

What Is libs.versions.toml?

Starting with Gradle 7 and Android Gradle Plugin 7+, Google introduced Version Catalogs — a new way to centralize and manage dependencies. Instead of scattering dependency strings across multiple build.gradle files, you can now define everything in a single place: libs.versions.toml.

This TOML (Tom’s Obvious Minimal Language) file lives in your project’s gradle folder and acts as your master dependency list.

Here’s what a basic libs.versions.toml file looks like:

[versions]
kotlin = "1.9.0"
coroutines = "1.7.1"

[libraries]
kotlin-stdlib = { module = "org.jetbrains.kotlin:kotlin-stdlib", version.ref = "kotlin" }
coroutines-core = { module = "org.jetbrains.kotlinx:kotlinx-coroutines-core", version.ref = "coroutines" }

That’s great — but what if you’re using the same group of libraries in every module? Writing them out repeatedly is a waste of time. That’s where Bundles in libs.versions.toml come to the rescue.

What Are Bundles?

Bundles are a feature of version catalogs that let you group related dependencies under a single name. Think of them like playlists for your libraries. Instead of referencing each dependency one by one, you just call the bundle, and you’re done.

Why Use Bundles?

• Clean, organized code
• No repeated dependencies
• Easy updates across modules
• Better modularization

How to Create a Bundle in libs.versions.toml

Let’s say you’re using multiple Jetpack Compose libraries across several modules. Without bundles, you’d need to add each one like this:

implementation(libs.compose.ui)
implementation(libs.compose.material)
implementation(libs.compose.tooling)

With Bundles in libs.versions.toml, you can simplify it like this:

Step 1: Define the Libraries

[versions]
compose = "1.5.0"

[libraries]
compose-ui = { module = "androidx.compose.ui:ui", version.ref = "compose" }
compose-material = { module = "androidx.compose.material:material", version.ref = "compose" }
compose-tooling = { module = "androidx.compose.ui:ui-tooling", version.ref = "compose" }

Step 2: Create a Bundle

[bundles]
compose = ["compose-ui", "compose-material", "compose-tooling"]

How to Use Bundles in build.gradle.kts

In your module’s build.gradle.kts file, just add:

implementation(libs.bundles.compose)

That one-liner brings in all the Compose dependencies you need. Clean, right?

Real-World Use Case: Networking Stack

Let’s say you always use Retrofit, Moshi, and OkHttp in your data modules. Define a bundle like this:

[versions]
retrofit = "2.9.0"
moshi = "1.13.0"
okhttp = "4.10.0"

[libraries]
retrofit-core = { module = "com.squareup.retrofit2:retrofit", version.ref = "retrofit" }
moshi-core = { module = "com.squareup.moshi:moshi", version.ref = "moshi" }
okhttp-core = { module = "com.squareup.okhttp3:okhttp", version.ref = "okhttp" }

[bundles]
networking = ["retrofit-core", "moshi-core", "okhttp-core"]

Then in your module:

implementation(libs.bundles.networking)

You’ve just replaced three lines with one — and centralized version control in the process.

Common Mistakes to Avoid

• Wrong syntax: The bundle array must reference exact keys from the [libraries] block.
• Missing versions: Always define versions under [versions] and refer using version.ref.
• Not reusing bundles: If two modules share the same libraries, don’t duplicate — bundle them.

Why Bundles in libs.versions.toml Matter for Android Developers

Bundles in libs.versions.toml are more than just a convenience—they’re a best practice. They improve your project structure, reduce maintenance overhead, and make scaling a breeze. Whether you’re working solo or on a large team, bundling dependencies is the smart way to manage complexity.

If you’re building modular Android apps (and let’s face it, who isn’t in 2025?), adopting bundles is a no-brainer.

Conclusion

The old way of managing dependencies is clunky and outdated. With Bundles in libs.versions.toml, you can streamline your workflow, stay DRY (Don’t Repeat Yourself), and future-proof your project.

Say goodbye to repetitive implementation lines and hello to clean, maintainable build scripts.

Start bundling today — and give your Android project the structure it deserves.

Managing data on Android has evolved significantly over the years. From SharedPreferences to Room, we’ve seen the full spectrum. But when it comes to storing structured, complex data in a lightweight and efficient way, Proto DataStore steps in as a game-changer.

In this blog, we’ll walk through Proto DataStore, how it works under the hood, and how to use it with Protocol Buffers to store complex objects. We’ll also look at how it stacks up against the older SharedPreferences and why it’s the better modern choice.

Let’s break it down step by step.

What is Proto DataStore?

Proto DataStore is a Jetpack library from Google that helps you store typed objects persistently using Protocol Buffers (protobuf), a fast and efficient serialization format.

It’s:

• Type-safe
• Asynchronous
• Corruption-resistant
• Better than SharedPreferences

Unlike Preferences DataStore, which stores data in key-value pairs (similar to SharedPreferences), Proto DataStore is ideal for storing structured data models.

Why Use Proto DataStore?

Here’s why developers love Proto DataStore:

• Strong typing — Your data models are generated and compiled, reducing runtime errors.
• Speed — Protocol Buffers are faster and more compact than JSON or XML.
• Safe and robust — Built-in corruption handling and data migration support.
• Asynchronous API — Uses Kotlin coroutines and Flow, keeping your UI smooth.

Store Complex Objects with Proto DataStore

Let’s go hands-on. Suppose you want to save a user profile with fields like name, email, age, and preferences.

Step 1: Add the Dependencies

Add these to your build.gradle (app-level):

dependencies {
    implementation "androidx.datastore:datastore:1.1.0"
    implementation "androidx.datastore:datastore-core:1.1.0"
    implementation "com.google.protobuf:protobuf-javalite:3.25.1"
}

In your build.gradle (project-level), enable Protobuf:

protobuf {
    protoc {
        artifact = "com.google.protobuf:protoc:3.25.1"
    }

    generateProtoTasks {
        all().each { task ->
            task.builtins {
                java { }
            }
        }
    }
}

Also apply plugins at the top:

plugins {
    id 'com.google.protobuf' version '0.9.4'
    id 'kotlin-kapt'
}

Step 2: Define Your .proto File

Create a file named user.proto inside src/main/proto/:

syntax = "proto3";

option java_package = "com.softaai.datastore";
option java_multiple_files = true;

message UserProfile {
  string name = 1;
  string email = 2;
  int32 age = 3;
  bool isDarkMode = 4;
}

This defines a structured data model for the user profile.

Step 3: Create the Serializer

Create a Kotlin class that implements Serializer<UserProfile>:

object UserProfileSerializer : Serializer<UserProfile> {
    override val defaultValue: UserProfile = UserProfile.getDefaultInstance()

    override suspend fun readFrom(input: InputStream): UserProfile {
        return UserProfile.parseFrom(input)
    }

    override suspend fun writeTo(t: UserProfile, output: OutputStream) {
        t.writeTo(output)
    }
}

This handles how the data is read and written to disk using protobuf.

Step 4: Initialize the Proto DataStore

Create a DataStore instance in your repository or a singleton:

val Context.userProfileDataStore: DataStore<UserProfile> by dataStore(
    fileName = "user_profile.pb",
    serializer = UserProfileSerializer
)

Now you can access this instance using context.userProfileDataStore.

Step 5: Read and Write Data

Here’s how you read the stored profile using Kotlin Flow:

val userProfileFlow: Flow<UserProfile> = context.userProfileDataStore.data

To update the profile:

suspend fun updateUserProfile(context: Context) {
    context.userProfileDataStore.updateData { currentProfile ->
        currentProfile.toBuilder()
            .setName("Amol Pawar")
            .setEmail("[email protected]")
            .setAge(28)
            .setIsDarkMode(true)
            .build()
    }
}

Easy, clean, and fully type-safe.

Bonus: Handling Corruption and Migration

Handle Corruption Gracefully

You can customize the corruption handler if needed:

val Context.safeUserProfileStore: DataStore<UserProfile> by dataStore(
    fileName = "user_profile.pb",
    serializer = UserProfileSerializer,
    corruptionHandler = ReplaceFileCorruptionHandler {
        UserProfile.getDefaultInstance()
    }
)

Migrate from SharedPreferences

If you’re switching from SharedPreferences:

val Context.migratedUserProfileStore: DataStore<UserProfile> by dataStore(
    fileName = "user_profile.pb",
    serializer = UserProfileSerializer,
    produceMigrations = { context ->
        listOf(SharedPreferencesMigration(context, "old_prefs_name"))
    }
)

When to Use Proto DataStore

Use Proto DataStore when:

• You need to persist complex, structured data.
• You care about performance and file size.
• You want a modern, coroutine-based data solution.

Avoid it for relational data (instead use Room) or for simple flags (Preferences DataStore may suffice).

Conclusion

Proto DataStore is the future-forward way to store structured data in Android apps. With Protocol Buffers at its core, it combines speed, safety, and type-safety into one clean package.

Whether you’re building a user profile system, app settings, or configuration storage, Proto DataStore helps you stay efficient and future-ready.

TL;DR

Q: What is Proto DataStore in Android?
 A: Proto DataStore is a modern Jetpack library that uses Protocol Buffers to store structured, type-safe data asynchronously and persistently.

Q: How do I store complex objects using Proto DataStore?
 A: Define a .proto schema, set up a serializer, initialize the DataStore, and read/write using Flow and coroutines.

Q: Why is Proto DataStore better than SharedPreferences?
 A: It’s type-safe, faster, handles corruption, and integrates with Kotlin coroutines.

If you’re still using SharedPreferences in your Android app, it’s time to move forward. Google introduced Jetpack DataStore as a modern, efficient, and fully asynchronous solution for storing key-value pairs and typed objects. In this blog, we’ll break down what Jetpack DataStore is, why it’s better than SharedPreferences, and how you can use it effectively in your Android projects.

What Is Jetpack DataStore?

Jetpack DataStore is part of Android Jetpack and is designed to store small amounts of data. It comes in two flavors:

• Preferences DataStore — stores key-value pairs, similar to SharedPreferences.
• Proto DataStore — stores typed objects using Protocol Buffers.

Unlike SharedPreferences, Jetpack DataStore is built on Kotlin coroutines and Flow, making it asynchronous and safe from potential ANRs (Application Not Responding errors).

Why Replace SharedPreferences?

SharedPreferences has been around for a long time but comes with some baggage:

• Synchronous API — can block the main thread.
• Lacks error handling — fails silently.
• Not type-safe — you can run into ClassCastExceptions easily.

Jetpack DataStore solves all of these with:

• Coroutine support for non-blocking IO.
• Strong typing with Proto DataStore.
• Built-in error handling.
• Better consistency and reliability.

Setting Up Jetpack DataStore

To start using Jetpack DataStore, first add the required dependencies to your build.gradle:

implementation "androidx.datastore:datastore-preferences:1.0.0"
implementation "androidx.datastore:datastore-core:1.0.0"

For Proto DataStore:

implementation "androidx.datastore:datastore:1.0.0"
implementation "com.google.protobuf:protobuf-javalite:3.14.0"

Also, don’t forget to apply the protobuf plugin if using Proto:

id 'com.google.protobuf' version '0.8.12'

Using Preferences DataStore

Step 1: Create the DataStore instance

Jetpack DataStore is designed to be singleton-scoped. The recommended way is to create it as an extension property on Context:

val Context.dataStore: DataStore<Preferences> by preferencesDataStore(name = "user_prefs")

Here, preferencesDataStore creates a singleton DataStore instance. This ensures you have a single DataStore instance per file, avoiding memory leaks and data corruption.

Step 2: Define keys

val USER_NAME = stringPreferencesKey("user_name")
val IS_LOGGED_IN = booleanPreferencesKey("is_logged_in")

stringPreferencesKey and booleanPreferencesKey help define the keys.

Step 3: Write data

To write data, use the edit function, which is fully asynchronous and safe to call from any thread:

suspend fun saveUserData(context: Context, name: String, isLoggedIn: Boolean) {
    context.dataStore.edit { preferences ->
        preferences[USER_NAME] = name
        preferences[IS_LOGGED_IN] = isLoggedIn
    }
}

Here, edit suspends while the data is being written, ensuring no UI thread blocking.

Step 4: Read data

To read data, use Kotlin Flows, which emit updates whenever the data changes:

val userNameFlow: Flow<String> = context.dataStore.data
    .map { preferences ->
        preferences[USER_NAME] ?: ""
    }

Here, data is accessed reactively using Kotlin Flow, returns a Flow<String> that emits the username whenever it changes. You can collect this Flow in a coroutine or observe it in Jetpack Compose.

Real-World Use Case: User Login State

Let’s say you want to keep track of whether a user is logged in. Here’s how you do it:

Save login state:

suspend fun setLoginState(context: Context, isLoggedIn: Boolean) {
    context.dataStore.edit { prefs ->
        prefs[IS_LOGGED_IN] = isLoggedIn
    }
}

Observe login state:

val loginState: Flow<Boolean> = context.dataStore.data
    .map { prefs -> prefs[IS_LOGGED_IN] ?: false }

This setup lets your app reactively respond to changes in the login state, such as redirecting users to the login screen or the home screen.

Migrating from SharedPreferences

Jetpack DataStore makes migration easy with SharedPreferencesMigration:

import androidx.datastore.preferences.SharedPreferencesMigration

val Context.dataStore by preferencesDataStore(
    name = USER_PREFERENCES_NAME,
    produceMigrations = { context ->
        listOf(SharedPreferencesMigration(context, USER_PREFERENCES_NAME))
    }
)

• Migration runs automatically before any DataStore access.
• Once migrated, stop using the old SharedPreferences to avoid data inconsistency.

Using Proto DataStore (Typed Data)

Proto DataStore requires you to define a .proto schema file.

Step 1: Define the Proto schema

user_prefs.proto

syntax = "proto3";

option java_package = "com.softaai.sitless";
option java_multiple_files = true;

message UserPreferences {
  string user_name = 1;
  bool is_logged_in = 2;
}

Step 2: Create the serializer

object UserPreferencesSerializer : Serializer<UserPreferences> {
    override val defaultValue: UserPreferences = UserPreferences.getDefaultInstance()

    override suspend fun readFrom(input: InputStream): UserPreferences {
        return UserPreferences.parseFrom(input)
    }

    override suspend fun writeTo(t: UserPreferences, output: OutputStream) {
        t.writeTo(output)
    }
}

Step 3: Initialize Proto DataStore

val Context.userPreferencesStore: DataStore<UserPreferences> by dataStore(
    fileName = "user_prefs.pb",
    serializer = UserPreferencesSerializer
)

Step 4: Update and read data

suspend fun updateUser(context: Context, name: String, isLoggedIn: Boolean) {
    context.userPreferencesStore.updateData { prefs ->
        prefs.toBuilder()
            .setUserName(name)
            .setIsLoggedIn(isLoggedIn)
            .build()
    }
}

val userNameFlow = context.userPreferencesStore.data
    .map { it.userName }

Best Practices

• Use Proto DataStore when your data model is complex or needs strong typing.
• Use Preferences DataStore for simple key-value storage.
• Always handle exceptions using catch when collecting flows.
• Avoid main-thread operations; DataStore is built for background execution.

Conclusion

Jetpack DataStore is not just a replacement for SharedPreferences; it’s an upgrade in every sense. With better performance, safety, and modern API design, it’s the future of local data storage in Android.

If you’re building a new Android app or refactoring an old one, now’s the perfect time to switch. By embracing Jetpack DataStore, you’re not only writing cleaner and safer code, but also aligning with best practices endorsed by Google.