Amol Pawar

Monochrome Icons

How Monochrome Icons Power Android Themed Icons (Android 12+)

Android 12 introduced one of the biggest visual upgrades in Android history: Material You.
At the heart of this design shift is a small but powerful feature called Monochrome Icons.

If you’ve ever noticed your app icons changing color to match your wallpaper, that’s Monochrome Icons doing their job.

In this guide, we’ll break down:

  • What Monochrome Icons are
  • How they power Android themed icons
  • Why Android 12+ relies on them
  • How to implement them correctly

What Are Monochrome Icons in Android?

Monochrome Icons are simplified versions of app icons that use a single color only.

They remove:

  • Gradients
  • Shadows
  • Multiple colors
  • Decorative details

Instead, they focus on shape and clarity.

Android uses these icons as a base to dynamically apply system colors based on the user’s wallpaper and theme.

In short:
Monochrome Icons are the foundation of Android themed icons.

Why Android 12+ Needs Monochrome Icons

Before Android 12, app icons were static. Every icon looked the same regardless of theme.

Android 12 changed this with dynamic theming, where the system extracts colors from the user’s wallpaper and applies them across:

  • Quick settings
  • Widgets
  • System UI
  • App icons

For this to work cleanly, Android needs icons that are easy to recolor. That’s where Monochrome Icons come in.

Without a proper monochrome layer, Android cannot theme your app icon correctly.

How Themed Icons Work Behind the Scenes

Here’s what happens when a user enables themed icons:

  1. Android checks if your app supports Monochrome Icons
  2. If supported, the system loads the monochrome drawable
  3. Android applies dynamic colors from the Material You palette
  4. The icon adapts instantly when wallpaper or theme changes

If your app does not include a monochrome icon:

  • The icon stays unchanged
  • It breaks visual consistency
  • It looks outdated next to themed apps

Where Monochrome Icons Live in Your App

Monochrome Icons are defined inside your adaptive icon XML.

This file is usually located at:

res/mipmap-anydpi-v26/ic_launcher.xml

This is where Android expects your monochrome icon to be declared.

Sample Adaptive Icon with Monochrome Support

Here’s a valid adaptive icon configuration:

XML
<?xml version="1.0" encoding="utf-8"?>
<adaptive-icon xmlns:android="http://schemas.android.com/apk/res/android">
    <background android:drawable="@color/ic_launcher_background" />
    <foreground android:drawable="@drawable/ic_launcher_foreground" />
    <monochrome android:drawable="@drawable/ic_launcher_monochrome" />
</adaptive-icon>

What Each Part Means

  • background
    Used for legacy launchers and non-themed states
  • foreground
    The full-color icon shown when themed icons are disabled
  • monochrome
    This is the key part
    Android uses this drawable for themed icons

If the <monochrome> tag is missing, themed icons won’t work for your app.

Designing a Proper Monochrome Icon

A good Monochrome Icon should:

  • Use solid white or black only
  • Avoid thin lines
  • Avoid transparency gradients
  • Focus on a recognizable shape

Recommended Format

  • Vector Drawable (.xml)
  • Single path
  • android:fillColor set to white or black
XML
<vector xmlns:android="http://schemas.android.com/apk/res/android"
    android:width="108dp"
    android:height="108dp"
    android:viewportWidth="108"
    android:viewportHeight="108">
    
<path
    android:fillColor="#FFFFFFFF"
    android:pathData="M20,20h68v68h-68z" />
</vector>

This simplicity is what allows Android to recolor it cleanly.

App Icon Configuration

Your launcher icon is referenced in AndroidManifest.xml:

XML
<application
    android:icon="@mipmap/ic_launcher"
    android:roundIcon="@mipmap/ic_launcher_round">

If your resources are misconfigured, Android won’t find the monochrome drawable.

Checking Android Version (Optional Use Case)

While Android handles themed icons automatically, you may want to check Android version in Kotlin for UI consistency elsewhere.

Kotlin
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
    // Android 12 or higher
    // Themed icons and Material You are supported
}
  • Build.VERSION.SDK_INT gives the device’s Android version
  • VERSION_CODES.S represents Android 12
  • This helps you align other UI elements with themed icons

Again, Monochrome Icons themselves do not need Kotlin logic.

Common Mistakes Developers Make

1. Using Colored Monochrome Icons

Monochrome means one solid color only.
Shades or gradients will break theming.

2. Overly Detailed Icons

Thin lines disappear when recolored.
Bold shapes work best.

3. Forgetting the <monochrome> Tag

Without it, Android ignores themed icons entirely.

4. Relying on PNGs

Vector drawables scale better and theme more reliably.

Why Monochrome Icons Improve User Experience

From a user perspective, Monochrome Icons:

  • Make the home screen feel cohesive
  • Reduce visual noise
  • Adapt naturally to dark and light themes
  • Feel modern and intentional

From a developer perspective:

  • Your app looks native on Android 12+
  • Better alignment with Material You
  • Improved visual trust and polish

Conclusion

Monochrome Icons may look simple, but they power one of Android’s most advanced design features.

If your app targets Android 12 or higher, supporting Monochrome Icons is no longer optional. It’s part of building a modern, user-first Android experience.

Keep your icons simple.
Let the system do the coloring.
And embrace Material You the way it was designed.

onValueChange = { value = it }

Understanding onValueChange = { value = it } in Jetpack Compose

Jetpack Compose introduces a very different mental model compared to XML-based Android UI. One line that often confuses beginners (and even experienced Android devs at first) is:

Kotlin
onValueChange = { value = it }

Especially when value is defined like this:

Kotlin
var value by remember { mutableStateOf(0) }

At first glance, this line looks almost too simple — and that’s exactly why it’s confusing. 

Let’s break down what’s really happening, why it’s written this way, and how it fits into Compose’s state-driven architecture.

The Big Picture: Compose Is State-Driven

Before diving into syntax, it’s important to understand how Compose thinks.

In classic Android:

  • You updated UI elements directly
  • UI held its own state
  • You manually synced UI ↔ data

In Jetpack Compose:

  • State owns the UI
  • UI is a function of state
  • When state changes → UI recomposes automatically

This single line:

Kotlin
onValueChange = { value = it }

is the bridge between user interaction and state updates.

What remember { mutableStateOf(...) } Really Does

Consider this state declaration:

Kotlin
var value by remember { mutableStateOf(0) }

This does three important things:

1. mutableStateOf

Creates an observable state holder.
Compose watches this value and tracks where it’s used.

2. remember

Ensures the state survives re-composition.
Without remember, the value would reset every time Compose redraws the UI.

3. by keyword

This is Kotlin property delegation. It allows you to write:

Kotlin
value = 5

instead of:

Kotlin
value.value = 5

So value behaves like a normal variable, but Compose is quietly observing it.

What onValueChange Is (Conceptually)

Most interactive Compose components (such as TextField, Slider, Checkbox) follow the same pattern:

Kotlin
Component(
    value = currentState,
    onValueChange = { /* update state */ }
)

This is intentional and consistent.

onValueChange is:

  • A callback function
  • Triggered every time the user interacts
  • Passed the new value as a parameter

Compose itself does not store the value internally.
You are responsible for updating the state.

Breaking Down { value = it }

Let’s rewrite the lambda in a more explicit way:

Kotlin
onValueChange = { newValue ->
    value = newValue
}

Now it’s clearer.

  • it (or newValue) is the latest value from the UI
  • value = it updates your state
  • Updating state triggers recomposition

This is not assigning a random variable — it’s updating the single source of truth.

How the Data Flow Actually Works

Here’s the real flow behind the scenes:

  1. User interacts with the UI (types text, drags slider, etc.)
  2. Compose calls onValueChange(newValue)
  3. You update state (value = newValue)
  4. Compose detects the state change
  5. Any composables reading value recompose automatically

This is called unidirectional data flow, and it’s a core Compose principle.

Kotlin
State → UI<br>UI interaction → Callback → State update → Recomposition

Simple Example with TextField

Kotlin
@Composable
fun NameInput() {
    var name by remember { mutableStateOf("") }

    TextField(
        value = name,
        onValueChange = { name = it },
        label = { Text("Enter your name") }
    )
}

Here,

  • name controls what the TextField displays
  • Typing triggers onValueChange
  • The new text is assigned to name
  • The TextField redraws with updated text

If you remove onValueChange, the field becomes read-only.

Why Compose Doesn’t Update the Value Automatically

This design is intentional.

Compose avoids hidden internal state because:

  • It prevents bugs
  • It makes UI predictable
  • It improves testability
  • It aligns with modern architecture (MVI, Redux-style patterns)

You always know where your data lives.

Common Beginner Mistakes

Forgetting to update state

Kotlin
onValueChange = { }

Result: UI never changes.

Not using remember

Kotlin
var value by mutableStateOf(0)

Result: Value resets on every recomposition.

Expecting Compose to “save” the value

Compose renders, it doesn’t store business state. That’s your job (or ViewModel’s).

Why This Pattern Is So Powerful

Once you understand this line, you understand 50% of Compose.

It enables:

  • Clean separation of UI and state
  • Easy state hoisting
  • Predictable recomposition
  • Seamless ViewModel integration

Example with state hoisting:

Kotlin
@Composable
fun Counter(value: Int, onValueChange: (Int) -> Unit) {
    Slider(
        value = value.toFloat(),
        onValueChange = { onValueChange(it.toInt()) }
    )
}

Now the parent owns the state — not the UI.

Final Mental Model (Remember This)

Compose does not mutate UI.
Compose reacts to state changes.

And this line:

JavaScript
onValueChange = { value = it }

is simply saying:

“When the user changes something, update my state — and let Compose handle the rest.”

Once this clicks, Jetpack Compose stops feeling confusing and starts feeling refreshingly simple..!

goAsync()

How goAsync() Works in BroadcastReceiver: Lifecycle, Pitfalls, and Best Practices

If you’ve ever worked with Android’s BroadcastReceiver, you know there’s a golden rule: keep your work quick. The system expects your receiver to finish in about 10 seconds, or it’ll label your app as unresponsive (ANR). But what happens when you need just a bit more time?

That’s exactly where goAsync() comes to the rescue.

In this guide, I’ll walk you through everything you need to know about goAsync() in BroadcastReceiver. We’ll explore how it works, when to use it, common mistakes developers make, and the best practices that’ll keep your Android apps running smoothly.

What Exactly Is goAsync()?

Let’s start with the basics. The goAsync() method is a special tool provided by the BroadcastReceiver class that gives you extra time to complete your work without blocking the main thread.

Normally, when a broadcast arrives, Android expects you to handle it immediately on the main thread. This works great for simple tasks like updating a variable or showing a notification. But what if you need to write to a database, make a quick network call, or perform some computation?

That’s the problem goAsync() solves.

When you call goAsync(), it returns a PendingResult object. This object essentially tells Android: “Hey, I’m not done yet, but I promise I’ll finish soon.” It extends your execution window beyond the typical onReceive() lifecycle.

The Lifecycle: How goAsync() Actually Works

Understanding the lifecycle is crucial to using goAsync() correctly. Let me break it down step by step.

Normal BroadcastReceiver Lifecycle

Here’s what happens in a regular broadcast receiver:

Kotlin
class SimpleBroadcastReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        // Your code runs here on the main thread
        Log.d("Receiver", "Broadcast received!")
        // When this method exits, the receiver is considered "done"
    }
}

The moment your onReceive() method finishes, Android assumes you’re done. The receiver becomes inactive, and the system may even kill your process if there’s no other component keeping it alive.

With goAsync() in the Picture

Now let’s see how goAsync() changes things:

Kotlin
class AsyncBroadcastReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        // Call goAsync() immediately to get a PendingResult
        val pendingResult: PendingResult = goAsync()
        
        // Now you can do work off the main thread
        CoroutineScope(Dispatchers.IO).launch {
            try {
                // Perform your background work here
                performLongRunningTask(context)
            } finally {
                // CRITICAL: Always call finish() when done
                pendingResult.finish()
            }
        }
    }
    
    private suspend fun performLongRunningTask(context: Context) {
        // Simulate some work
        delay(3000)
        Log.d("Receiver", "Task completed!")
    }
}

Here’s what’s happening behind the scenes:

  1. goAsync() is called: This immediately returns a PendingResult object and tells Android the receiver is still working
  2. Work happens off-thread: You move your heavy lifting to a background thread using coroutines or another threading mechanism
  3. finish() is called: When you’re done, calling pendingResult.finish() signals to Android that the receiver has completed its work

The key difference? Your process stays alive even after onReceive() returns, as long as you haven’t called finish() yet.

When Should You Use goAsync()?

The goAsync() method isn’t meant for every situation. Here’s when it makes sense to reach for it:

Perfect Use Cases

Database Operations: Writing user preferences or logging data that takes 2–3 seconds.

Kotlin
class DataSavingReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val pendingResult = goAsync()
        
        CoroutineScope(Dispatchers.IO).launch {
            try {
                val database = AppDatabase.getInstance(context)
                val data = intent.getStringExtra("data") ?: return@launch
                
                // This database write might take a few seconds
                database.userDao().insertData(data)
                Log.d("Receiver", "Data saved successfully")
            } finally {
                pendingResult.finish()
            }
        }
    }
}

Quick Network Calls: Sending analytics events or pinging a server (though WorkManager is often better for this).

File I/O: Reading or writing small amounts of data to storage.

When NOT to Use goAsync()

Long-running tasks: Anything taking more than 10 seconds should use WorkManager, JobScheduler, or a foreground service instead.

Complex operations: If your task requires multiple steps that could fail, consider a more robust solution.

Simple tasks: If your work takes less than a millisecond, you don’t need goAsync() at all. Just do it directly in onReceive().

Common Pitfalls and How to Avoid Them

I’ve seen developers stumble over the same issues when using goAsync(). Let me save you from these headaches.

Pitfall 1: Forgetting to Call finish()

This is the number one mistake. If you never call finish(), Android keeps your receiver alive indefinitely, wasting system resources.

Kotlin
// BAD: Missing finish() call
class BadReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val pendingResult = goAsync()
        
        CoroutineScope(Dispatchers.IO).launch {
            performTask()
            // Oops..! Forgot to call pendingResult.finish()
        }
    }
}

Always use a try-finally block or Kotlin’s use pattern to ensure finish() gets called:

Kotlin
// GOOD: Guaranteed finish() call
class GoodReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val pendingResult = goAsync()
        
        CoroutineScope(Dispatchers.IO).launch {
            try {
                performTask()
            } catch (e: Exception) {
                Log.e("Receiver", "Error: ${e.message}")
            } finally {
                pendingResult.finish()
            }
        }
    }
}

Pitfall 2: Running on the Main Thread

Calling goAsync() doesn’t automatically move your work off the main thread. You still need to handle that yourself.

Kotlin
// BAD: Still blocking the main thread
class BlockingReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val pendingResult = goAsync()
        
        // This still runs on the main thread!
        Thread.sleep(5000) // Don't do this!
        
        pendingResult.finish()
    }
}

Always explicitly move to a background thread:

Kotlin
// GOOD: Work happens on background thread
class NonBlockingReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val pendingResult = goAsync()
        
        // Using Dispatchers.IO for background work
        CoroutineScope(Dispatchers.IO).launch {
            try {
                delay(5000) // This is okay on IO thread
                processData()
            } finally {
                pendingResult.finish()
            }
        }
    }
}

Pitfall 3: Exceeding the Time Limit

Even with goAsync(), you still have time constraints. Android gives you approximately 10 seconds total. Going beyond that results in an ANR.

Kotlin
class TimeConsciousReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val pendingResult = goAsync()
        
        CoroutineScope(Dispatchers.IO).launch {
            try {
                withTimeout(8000) { // Set a timeout slightly under 10 seconds
                    performTaskWithTimeout()
                }
            } catch (e: TimeoutCancellationException) {
                Log.e("Receiver", "Task took too long")
            } finally {
                pendingResult.finish()
            }
        }
    }
}

Pitfall 4: Memory Leaks with Context

Be careful about holding onto the Context object in your background work. The context passed to onReceive() is short-lived.

Kotlin
// SAFER: Use application context for long-running work
class SafeContextReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val pendingResult = goAsync()
        val appContext = context.applicationContext // Use app context
        
        CoroutineScope(Dispatchers.IO).launch {
            try {
                // Use appContext instead of context
                doWorkWith(appContext)
            } finally {
                pendingResult.finish()
            }
        }
    }
}

Best Practices for Using goAsync()

After working with goAsync() across multiple projects, here are my recommended best practices.

1. Always Use Structured Concurrency

Kotlin coroutines with proper scope management make your life easier:

Kotlin
class StructuredReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val pendingResult = goAsync()
        
        // Create a supervised scope
        val scope = CoroutineScope(SupervisorJob() + Dispatchers.IO)
        
        scope.launch {
            try {
                // All your async work here
                val result = performNetworkCall()
                saveToDatabase(context, result)
            } catch (e: Exception) {
                handleError(e)
            } finally {
                pendingResult.finish()
                scope.cancel() // Clean up the scope
            }
        }
    }
}

2. Implement Proper Error Handling

Things will go wrong. Handle exceptions gracefully:

Kotlin
class RobustReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val pendingResult = goAsync()
        
        CoroutineScope(Dispatchers.IO).launch {
            try {
                val data = intent.getStringExtra("key") 
                    ?: throw IllegalArgumentException("Missing data")
                
                processData(data)
                
            } catch (e: IllegalArgumentException) {
                Log.e("Receiver", "Invalid input: ${e.message}")
            } catch (e: IOException) {
                Log.e("Receiver", "Network error: ${e.message}")
            } catch (e: Exception) {
                Log.e("Receiver", "Unexpected error: ${e.message}")
            } finally {
                pendingResult.finish()
            }
        }
    }
}

3. Add Logging for Debugging

When things go wrong, good logs are your best friend:

Kotlin
class LoggingReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        Log.d(TAG, "Broadcast received: ${intent.action}")
        val startTime = System.currentTimeMillis()
        val pendingResult = goAsync()
        
        CoroutineScope(Dispatchers.IO).launch {
            try {
                Log.d(TAG, "Starting background work")
                performWork()
                Log.d(TAG, "Work completed successfully")
            } catch (e: Exception) {
                Log.e(TAG, "Work failed", e)
            } finally {
                val duration = System.currentTimeMillis() - startTime
                Log.d(TAG, "Total execution time: ${duration}ms")
                pendingResult.finish()
            }
        }
    }
    
    companion object {
        private const val TAG = "LoggingReceiver"
    }
}

4. Consider WorkManager for Complex Tasks

If your task is getting complicated, it might be time to switch to WorkManager:

Kotlin
class SmartReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val taskComplexity = estimateComplexity(intent)
        
        when {
            taskComplexity < 3 -> {
                // Simple task: use goAsync()
                val pendingResult = goAsync()
                CoroutineScope(Dispatchers.IO).launch {
                    try {
                        quickTask()
                    } finally {
                        pendingResult.finish()
                    }
                }
            }
            else -> {
                // Complex task: delegate to WorkManager
                val workRequest = OneTimeWorkRequestBuilder<DataSyncWorker>()
                    .setInputData(workDataOf("data" to intent.getStringExtra("data")))
                    .build()
                WorkManager.getInstance(context).enqueue(workRequest)
            }
        }
    }
}

Real-World Example: Network Sync on Connectivity Change

Let’s put everything together with a practical example. This receiver syncs data when the device connects to WiFi:

Kotlin
class ConnectivitySyncReceiver : BroadcastReceiver() {
    
    override fun onReceive(context: Context, intent: Intent) {
        // Check if this is a connectivity change
        if (intent.action != ConnectivityManager.CONNECTIVITY_ACTION) {
            return
        }
        
        Log.d(TAG, "Connectivity changed")

        val pendingResult = goAsync()
        val appContext = context.applicationContext
        
        CoroutineScope(Dispatchers.IO).launch {
            try {
                // Check if we're on WiFi
                if (!isWiFiConnected(appContext)) {
                    Log.d(TAG, "Not on WiFi, skipping sync")
                    return@launch
                }
                
                Log.d(TAG, "WiFi connected, starting sync")
                
                // Perform sync with timeout
                withTimeout(8000) {
                    syncDataWithServer(appContext)
                }
                
                Log.d(TAG, "Sync completed successfully")
                
            } catch (e: TimeoutCancellationException) {
                Log.e(TAG, "Sync timed out")
                scheduleRetryWithWorkManager(appContext)
            } catch (e: IOException) {
                Log.e(TAG, "Network error during sync", e)
            } catch (e: Exception) {
                Log.e(TAG, "Unexpected error during sync", e)
            } finally {
                pendingResult.finish()
            }
        }
    }
    
    private fun isWiFiConnected(context: Context): Boolean {
        val cm = context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
        val network = cm.activeNetwork ?: return false
        val capabilities = cm.getNetworkCapabilities(network) ?: return false
        return capabilities.hasTransport(NetworkCapabilities.TRANSPORT_WIFI)
    }
    
    private suspend fun syncDataWithServer(context: Context) {
        // Simulate API call
        delay(2000)
        
        // In reality, you'd make an actual network call here
        val repository = DataRepository.getInstance(context)
        repository.syncWithServer()
    }
    
    private fun scheduleRetryWithWorkManager(context: Context) {
        val retryWork = OneTimeWorkRequestBuilder<SyncWorker>()
            .setInitialDelay(15, TimeUnit.MINUTES)
            .build()
        WorkManager.getInstance(context).enqueue(retryWork)
    }
    
    companion object {
        private const val TAG = "ConnectivitySync"
    }
}

This example demonstrates several best practices:

  • Immediate goAsync() call to extend execution time
  • Application context usage to prevent memory leaks
  • Proper exception handling for different error scenarios
  • Timeout protection to avoid ANRs
  • Fallback to WorkManager for retry logic
  • Comprehensive logging for debugging

Testing Your goAsync() Implementation

Testing broadcast receivers with goAsync() requires special attention. Here’s a simple approach:

Kotlin
@Test
fun testAsyncBroadcastReceiver() = runBlocking {
    val context = ApplicationProvider.getApplicationContext<Context>()
    val intent = Intent("com.softaai.TEST_ACTION")
    val receiver = AsyncBroadcastReceiver()
    
    // Set up a CountDownLatch to wait for async completion
    val latch = CountDownLatch(1)
    
    // Mock the receiver to signal when done
    receiver.onReceive(context, intent)
    
    // Wait for async work to complete (with timeout)
    val completed = latch.await(5, TimeUnit.SECONDS)
    assertTrue("Receiver should complete within timeout", completed)
}

Conclusion

The goAsync() method is a powerful tool in your Android development toolkit, but it requires careful handling. 

Let me recap the key points:

What goAsync() does: Extends the execution window for your BroadcastReceiver beyond the typical onReceive() lifecycle

When to use it: For tasks taking 1–8 seconds, like database writes, quick network calls, or file I/O

Critical rules: Always call finish(), move work off the main thread, respect the 10-second limit, and handle errors gracefully

Better alternatives: For longer tasks or complex workflows, consider WorkManager, JobScheduler, or foreground services

Remember, goAsync() is meant for those in-between moments when your work is too heavy for the main thread but too quick to justify a full background service. Use it wisely, follow the best practices we’ve covered, and your broadcast receivers will run smoothly without causing ANRs or draining battery life.

State Management in Jetpack Compose

Modern State Management in Jetpack Compose: Flows, Side Effects, and UI State

State management is the backbone of any modern Android app. If state is messy, your UI becomes unpredictable, buggy, and hard to maintain. Jetpack Compose was designed to solve many of these problems, but only if you understand how State Management in Jetpack Compose actually works.

In this post, we will break down modern state management in Jetpack Compose using simple examples. We will cover UI state, Kotlin Flows, side effects, and how they all fit together in a clean, scalable way.

What Does State Mean in Jetpack Compose?

In simple terms, state is data that the UI depends on.

If the state changes, the UI should update automatically.

Examples of state:

  • A loading flag
  • A list of items
  • User input text
  • An error message

Jetpack Compose is state-driven. This means you do not tell the UI how to update. You just update the state, and Compose handles the rest.

This is the foundation of State Management in Jetpack Compose.

UI State vs Business Logic

A common beginner mistake is mixing UI state with business logic. Modern Compose apps separate these responsibilities.

  • UI state describes what the screen looks like
  • Business logic decides how data changes

The ViewModel is the bridge between them.

Designing UI State the Right Way

A good UI state is:

  • Immutable
  • Easy to read
  • Represents the entire screen

Let’s start with a simple UI state class.

Kotlin
data class UserUiState(
    val isLoading: Boolean = false,
    val userName: String = "",
    val errorMessage: String? = null
)

Why this works well

  • It represents the full UI in one place
  • It avoids multiple scattered states
  • It makes the UI predictable

This pattern is widely recommended for State Management in Jetpack Compose because it scales well as your app grows.

Using ViewModel for State Management

The ViewModel holds the UI state and exposes it to the UI.

Kotlin
class UserViewModel : ViewModel() {

    private val _uiState = MutableStateFlow(UserUiState())
    val uiState: StateFlow<UserUiState> = _uiState.asStateFlow()

    fun loadUser() {
        _uiState.value = _uiState.value.copy(isLoading = true)
        viewModelScope.launch {
            delay(2000)
            _uiState.value = UserUiState(
                isLoading = false,
                userName = "Amol"
            )
        }
    }
}
  • MutableStateFlow holds mutable state inside the ViewModel
  • StateFlow is exposed as read-only to the UI (asStateFlow() exposes a read-only version to the UI)
  • copy() updates only the fields that change

This approach keeps state changes controlled and safe.

Why Kotlin Flow Is Preferred in Modern Compose

Kotlin Flow is a cold asynchronous data stream. In Compose, it works beautifully with recomposition.

Benefits:

  • Lifecycle-aware (collectAsStateWithLifecycle())
  • Handles async data naturally
  • Works perfectly with ViewModel

This is why Flow is central to State Management in Jetpack Compose.

Collecting State in Composables

Now let’s connect the ViewModel to the UI.

Kotlin
@Composable
fun UserScreen(viewModel: UserViewModel = viewModel()) {

    val uiState by viewModel.uiState.collectAsStateWithLifecycle()

    when {
        uiState.isLoading -> {
            CircularProgressIndicator()
        }
        uiState.errorMessage != null -> {
            Text(text = uiState.errorMessage)
        }
        else -> {
            Text(text = "Hello, ${uiState.userName}")
        }
    }
}

What is happening here

  • collectAsStateWithLifecycle() converts Flow into Compose state
  • Compose automatically recomposes when state changes
  • UI stays in sync with data

This is declarative UI in action.

Understanding Side Effects in Jetpack Compose

Side effects are operations that happen outside the scope of a composable function. Think network calls, database writes, or analytics events. Compose provides several side effect handlers, each with specific use cases.

LaunchedEffect: For Coroutine-Based Side Effects

Use LaunchedEffect when you need to run suspend functions:

Kotlin
@Composable
fun SearchScreen(viewModel: SearchViewModel = viewModel()) {
    var searchQuery by remember { mutableStateOf("") }
    val searchResults by viewModel.searchResults.collectAsStateWithLifecycle()
    
    LaunchedEffect(searchQuery) {
        // Debounce search queries
        delay(300)
        if (searchQuery.isNotEmpty()) {
            viewModel.search(searchQuery)
        }
    }
    
    Column {
        SearchBar(
            query = searchQuery,
            onQueryChange = { searchQuery = it }
        )
        SearchResultsList(results = searchResults)
    }
}

Why this works:

  • LaunchedEffect(searchQuery) cancels and restarts when searchQuery changes
  • The delay(300) creates a debounce effect—search only happens if the user stops typing for 300ms
  • This prevents excessive network calls while typing

DisposableEffect: Cleanup When You Leave

When you need to clean up resources, DisposableEffect is your friend:

Kotlin
@Composable
fun LocationTracker() {
    val context = LocalContext.current
    
    DisposableEffect(Unit) {
        val locationManager = context.getSystemService(Context.LOCATION_SERVICE) 
            as LocationManager
        
        val listener = object : LocationListener {
            override fun onLocationChanged(location: Location) {
                // Handle location update
            }
            // Other required methods...
        }
        
        // Request location updates
        locationManager.requestLocationUpdates(
            LocationManager.GPS_PROVIDER,
            1000L,
            10f,
            listener
        )
        
        // Cleanup when composable leaves composition
        onDispose {
            locationManager.removeUpdates(listener)
        }
    }
}

Here,

  • DisposableEffect(Unit) runs once when the composable enters composition
  • The code inside runs to set up the location listener
  • onDispose runs when the composable leaves—perfect for cleanup
  • This prevents memory leaks from lingering listeners

SideEffect: For Non-Suspend Operations

Use SideEffect for things that should happen after every successful recomposition:

Kotlin
@Composable
fun AnalyticsScreen(screenName: String) {
    val analytics = remember { Firebase.analytics }
    
    SideEffect {
        // This runs after every successful composition
        analytics.logEvent("screen_view") {
            param("screen_name", screenName)
        }
    }
    
    // Your UI content here
}

The difference:

  • SideEffect runs after every recomposition that completes successfully
  • It’s for operations that don’t involve suspend functions
  • Great for logging, analytics, or updating non-Compose code

Advanced State Management Patterns

Now that we’ve covered the basics, let’s explore patterns that’ll level up your state management in Jetpack Compose game.

The Single Source of Truth Pattern

Always maintain one source of truth for your state:

Kotlin
class ShoppingCartViewModel : ViewModel() {
    private val _cartState = MutableStateFlow(CartState())
    val cartState = _cartState.asStateFlow()
    
    fun addItem(item: Product) {
        _cartState.update { currentState ->
            val existingItem = currentState.items.find { it.product.id == item.id }
            
            if (existingItem != null) {
                // Increase quantity
                currentState.copy(
                    items = currentState.items.map { cartItem ->
                        if (cartItem.product.id == item.id) {
                            cartItem.copy(quantity = cartItem.quantity + 1)
                        } else {
                            cartItem
                        }
                    }
                )
            } else {
                // Add new item
                currentState.copy(
                    items = currentState.items + CartItem(item, 1)
                )
            }
        }
    }
    
    fun removeItem(productId: String) {
        _cartState.update { currentState ->
            currentState.copy(
                items = currentState.items.filter { it.product.id != productId }
            )
        }
    }
}

data class CartState(
    val items: List<CartItem> = emptyList()
) {
    val totalPrice: Double
        get() = items.sumOf { it.product.price * it.quantity }
    
    val itemCount: Int
        get() = items.sumOf { it.quantity }
}

data class CartItem(
    val product: Product,
    val quantity: Int
)

Why this pattern rocks:

  • All cart logic lives in one place
  • Derived values like totalPrice are computed properties
  • State updates are atomic and predictable
  • The UI just reacts to state changes

Combining Multiple Flows

Often you need to combine data from multiple sources:

Kotlin
class DashboardViewModel(
    private val userRepository: UserRepository,
    private val notificationRepository: NotificationRepository
) : ViewModel() {
    
    val dashboardState: StateFlow<DashboardUiState> = combine(
        userRepository.currentUser,
        notificationRepository.unreadCount
    ) { user, unreadCount ->
        DashboardUiState(
            userName = user?.name ?: "Guest",
            unreadNotifications = unreadCount,
            isLoggedIn = user != null
        )
    }.stateIn(
        scope = viewModelScope,
        started = SharingStarted.WhileSubscribed(5000),
        initialValue = DashboardUiState()
    )
}

data class DashboardUiState(
    val userName: String = "",
    val unreadNotifications: Int = 0,
    val isLoggedIn: Boolean = false
)

Here,

  • combine merges multiple flows into one
  • Whenever either source flow emits, the lambda recalculates the state
  • stateIn converts the regular flow to StateFlow
  • WhileSubscribed(5000) keeps the flow active for 5 seconds after the last subscriber leaves
  • This is efficient state management in Jetpack Compose for complex scenarios

Handling Loading States Elegantly

Here’s a pattern I use for handling async operations:

Kotlin
sealed class UiState<out T> {
    object Idle : UiState<Nothing>()
    object Loading : UiState<Nothing>()
    data class Success<T>(val data: T) : UiState<T>()
    data class Error(val message: String) : UiState<Nothing>()
}

class ProductViewModel : ViewModel() {
    private val _productState = MutableStateFlow<UiState<Product>>(UiState.Idle)
    val productState = _productState.asStateFlow()
    
    fun loadProduct(productId: String) {
        viewModelScope.launch {
            _productState.value = UiState.Loading
            
            try {
                val product = productRepository.getProduct(productId)
                _productState.value = UiState.Success(product)
            } catch (e: Exception) {
                _productState.value = UiState.Error(
                    e.message ?: "Unknown error occurred"
                )
            }
        }
    }
}

And here’s how you’d consume it:

Kotlin
@Composable
fun ProductScreen(
    productId: String,
    viewModel: ProductViewModel = viewModel()
) {
    val productState by viewModel.productState.collectAsStateWithLifecycle()
    
    LaunchedEffect(productId) {
        viewModel.loadProduct(productId)
    }
    
    Box(modifier = Modifier.fillMaxSize()) {
        when (val state = productState) {
            is UiState.Idle -> {
                // Show nothing or a placeholder
            }
            is UiState.Loading -> {
                CircularProgressIndicator(
                    modifier = Modifier.align(Alignment.Center)
                )
            }
            is UiState.Success -> {
                ProductDetails(product = state.data)
            }
            is UiState.Error -> {
                ErrorView(
                    message = state.message,
                    onRetry = { viewModel.loadProduct(productId) }
                )
            }
        }
    }
}

Why sealed classes are perfect here:

  • Exhaustive when expressions — the compiler ensures you handle all cases
  • Type-safe data access — state.data only exists in Success
  • Clear state representation
  • Easy to test each state

State Hoisting: Keeping Composables Reusable

State hoisting is a pattern where you move state up to make composables stateless and reusable. This is crucial for good state management in Jetpack Compose.

Before State Hoisting (Don’t Do This)

Kotlin
@Composable
fun SearchBar() {
    var query by remember { mutableStateOf("") }
    
    TextField(
        value = query,
        onValueChange = { query = it },
        placeholder = { Text("Search...") }
    )
}

This looks simple, but the state is trapped inside. You can’t access or control it from outside.

After State Hoisting (Much Better)

Kotlin
@Composable
fun SearchBar(
    query: String,
    onQueryChange: (String) -> Unit,
    modifier: Modifier = Modifier
) {
    TextField(
        value = query,
        onValueChange = onQueryChange,
        placeholder = { Text("Search...") },
        modifier = modifier
    )
}

// Usage
@Composable
fun SearchScreen() {
    var searchQuery by remember { mutableStateOf("") }
    
    Column {
        SearchBar(
            query = searchQuery,
            onQueryChange = { searchQuery = it }
        )
        // Now you can use searchQuery for other things!
        if (searchQuery.isNotEmpty()) {
            Text("Searching for: $searchQuery")
        }
    }
}

The benefits:

  • SearchBar is now stateless and testable
  • You can preview it easily with different values
  • State is controlled from the parent
  • Reusable across different screens

Remember: Choose the Right Tool

Compose provides different remember variants for different scenarios:

remember vs rememberSaveable

Kotlin
@Composable
fun FormScreen() {
    // Lost on configuration change (screen rotation)
    var tempData by remember { mutableStateOf("") }
    
    // Survives configuration changes
    var importantData by rememberSaveable { mutableStateOf("") }
    
    // For complex objects, use a custom Saver
    var complexData by rememberSaveable(stateSaver = ComplexDataSaver) {
        mutableStateOf(ComplexData())
    }
}

When to use what:

  • Use remember for temporary UI state that can be regenerated
  • Use rememberSaveable for user input or important state
  • Both are cleared when the composable leaves composition permanently

rememberCoroutineScope for Manual Control

Kotlin
@Composable
fun AnimatedButton() {
    val scope = rememberCoroutineScope()
    val scale = remember { Animatable(1f) }
    
    Button(
        onClick = {
            scope.launch {
                scale.animateTo(1.2f)
                scale.animateTo(1f)
            }
        }
    ) {
        Text(
            text = "Press Me",
            modifier = Modifier.scale(scale.value)
        )
    }
}
  • rememberCoroutineScope() gives you a scope tied to the composable’s lifecycle
  • Perfect for launching coroutines from event handlers
  • Automatically cancelled when the composable leaves

Derived State: Computing Values Efficiently

Sometimes you need to compute values from existing state. Use derivedStateOf to optimize:

Kotlin
@Composable
fun FilteredList(items: List<String>) {
    var searchQuery by remember { mutableStateOf("") }
    
    // Only recalculates when items or searchQuery actually change
    val filteredItems by remember(items, searchQuery) {
        derivedStateOf {
            if (searchQuery.isEmpty()) {
                items
            } else {
                items.filter { it.contains(searchQuery, ignoreCase = true) }
            }
        }
    }
    
    Column {
        SearchBar(
            query = searchQuery,
            onQueryChange = { searchQuery = it }
        )
        LazyColumn {
            items(filteredItems) { item ->
                Text(item)
            }
        }
    }
}

The magic here:

  • Without derivedStateOf, filtering would happen on every recomposition
  • With it, filtering only happens when dependencies change
  • This is essential for expensive computations

Testing Your State Management

Good state management in Jetpack Compose means testable code. Here’s how:

Kotlin
class ShoppingCartViewModelTest {
    @Test
    fun `adding item increases cart count`() = runTest {
        val viewModel = ShoppingCartViewModel()
        val testProduct = Product(id = "1", name = "Test", price = 10.0)
        
        viewModel.addItem(testProduct)
        
        val state = viewModel.cartState.value
        assertEquals(1, state.itemCount)
        assertEquals(10.0, state.totalPrice, 0.01)
    }
    
    @Test
    fun `removing item decreases cart count`() = runTest {
        val viewModel = ShoppingCartViewModel()
        val testProduct = Product(id = "1", name = "Test", price = 10.0)
        
        viewModel.addItem(testProduct)
        viewModel.removeItem(testProduct.id)
        
        val state = viewModel.cartState.value
        assertEquals(0, state.itemCount)
        assertEquals(0.0, state.totalPrice, 0.01)
    }
}

Testing benefits:

  • State logic is isolated in ViewModels
  • Easy to verify state transformations
  • No UI testing needed for business logic
  • Fast, reliable tests

Common Pitfalls to Avoid

Let me save you some headaches by pointing out common mistakes:

Pitfall 1: Unnecessary Recompositions

Kotlin
// Bad: Creates a new list on every recomposition
@Composable
fun BadExample() {
    val items = listOf("A", "B", "C")  // New list every time!
}

// Good: Remember the list
@Composable
fun GoodExample() {
    val items = remember { listOf("A", "B", "C") }
}

Pitfall 2: Calling Suspend Functions Directly

Kotlin
// Bad: This will crash
@Composable
fun BadNetworkCall() {
    val data = repository.getData()  // Suspend function!
}

// Good: Use LaunchedEffect
@Composable
fun GoodNetworkCall(viewModel: MyViewModel) {
    val data by viewModel.data.collectAsStateWithLifecycle()
    
    LaunchedEffect(Unit) {
        viewModel.loadData()
    }
}

Pitfall 3: Modifying State Outside Composition

Kotlin
// Bad: State update in initialization
@Composable
fun BadStateUpdate(viewModel: MyViewModel) {
    viewModel.updateState()  // Don't do this..!
}

// Good: Use side effects
@Composable
fun GoodStateUpdate(viewModel: MyViewModel) {
    LaunchedEffect(Unit) {
        viewModel.updateState()
    }
}

Best Practices for State Management in Jetpack Compose

Here are proven guidelines used in real production apps:

  • Use a single UI state per screen
  • Keep state immutable
  • Expose state as StateFlow
  • Handle side effects explicitly
  • Avoid mutable state in Composables
  • Let ViewModel own the logic

Following these keeps your app stable and testable.

Conclusion

Modern State Management in Jetpack Compose is not complicated once you understand the core ideas. State flows down. Events flow up. Side effects are handled explicitly.

Jetpack Compose rewards clean thinking. If your state is simple and predictable, your UI will be too.

Start small. Keep state clear. Let Compose do the heavy lifting.

Process Death in Android

What Is Process Death in Android? Causes, Examples, and How to Handle It

Have you ever opened an app on your Android phone, switched to another app for a while, and then returned only to find everything reset? Your form data gone, your scroll position lost, or the app back at the home screen?

That’s Process Death in Android.

Understanding Process Death in Android is crucial for building apps that feel reliable and professional. In this guide, we’ll explore what it is, why it happens, and most importantly, how to handle it properly in your Android apps.

What Exactly Is Process Death in Android?

Process Death in Android occurs when the Android operating system kills your app’s process to free up memory for other apps. Think of it like your phone doing some housekeeping — when memory gets tight, Android decides which apps to close to keep everything running smoothly.

Here’s the tricky part: when your app’s process dies, your activities might still appear to be in the back stack. When the user returns, Android recreates the activity, but all your runtime data is gone unless you’ve saved it properly.

This is different from the normal activity lifecycle. Your app doesn’t just pause or stop — it’s completely terminated and then brought back to life.

Why Does Process Death Happen?

Android needs to manage limited device resources efficiently. Here are the main reasons Process Death in Android occurs:

Low Memory Situations

When your device runs low on RAM, Android starts killing background processes. Apps you haven’t used recently are the first to go.

Developer Options Testing

During development, you can enable “Don’t keep activities” in Developer Options. This immediately destroys activities when they leave the foreground, making it easier to test Process Death scenarios.

Long Background Duration

If your app stays in the background for an extended period while the user uses other memory-intensive apps, there’s a higher chance your process will be killed.

System Updates or Crashes

Sometimes system events or crashes can trigger process termination across multiple apps.

Real-World Example: The Shopping Cart Problem

Let me share a common scenario that illustrates Process Death in Android perfectly.

Imagine you’re building a shopping app. A user adds five items to their cart, then switches to their messaging app to check a friend’s recommendation. They spend 10 minutes chatting, during which Android kills your shopping app’s process to free memory.

When they return to your app, if you haven’t handled Process Death properly, their cart is empty. 

Frustrating, right?

This is exactly why understanding and handling Process Death in Android matters for user experience.

How to Detect Process Death in Android

Before we fix it, let’s learn how to detect it. Add this code to your activity:

Kotlin
class MainActivity : AppCompatActivity() {
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        
        if (savedInstanceState != null) {
            // Activity was recreated after process death
            Log.d("ProcessDeath", "Activity restored after process death")
        } else {
            // Normal first-time creation
            Log.d("ProcessDeath", "Activity created normally")
        }
    }
}

The onCreate() method receives a savedInstanceState parameter. When this parameter is not null, it means Android is restoring your activity after Process Death. If it’s null, your activity is being created for the first time or normally resumed.

This simple check helps you understand when restoration is happening.

Saving State with onSaveInstanceState

The primary way to handle Process Death in Android is by overriding onSaveInstanceState(). This method is called before your activity might be destroyed, giving you a chance to save important data.

Kotlin
class ShoppingCartActivity : AppCompatActivity() {
    
    private var cartItems = mutableListOf<String>()
    private var totalPrice = 0.0
    private var userName = ""
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_shopping_cart)
        
        // Restore saved state if available
        savedInstanceState?.let {
            cartItems = it.getStringArrayList("CART_ITEMS")?.toMutableList() ?: mutableListOf()
            totalPrice = it.getDouble("TOTAL_PRICE", 0.0)
            userName = it.getString("USER_NAME", "")
            
            Log.d("ProcessDeath", "Restored ${cartItems.size} items")
        }
        
        updateUI()
    }
    
    override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)
        
        // Save critical data before potential process death
        outState.putStringArrayList("CART_ITEMS", ArrayList(cartItems))
        outState.putDouble("TOTAL_PRICE", totalPrice)
        outState.putString("USER_NAME", userName)
        
        Log.d("ProcessDeath", "Saved ${cartItems.size} items to bundle")
    }
    
    private fun updateUI() {
        // Update your UI with restored data
        findViewById<TextView>(R.id.itemCount).text = "Items: ${cartItems.size}"
        findViewById<TextView>(R.id.totalPrice).text = "Total: $$totalPrice"
    }
}

Here, we override two key methods:

  1. onSaveInstanceState(): This is where we save our data to a Bundle. Think of a Bundle as a container that Android keeps safe even during Process Death. We use methods like putStringArrayList(), putDouble(), and putString() to store different data types.
  2. onCreate(): We check if savedInstanceState exists. If it does, we restore our data using corresponding get methods like getStringArrayList() and getDouble().

The ?.let syntax is Kotlin’s safe call operator, ensuring we only access the bundle if it’s not null.

What Data Can You Save in a Bundle?

Bundles support many common data types, but there are limitations. Here’s what you can save:

Supported Types:

  • Primitive types (Int, Long, Float, Double, Boolean)
  • Strings and CharSequences
  • Parcelable objects
  • Serializable objects
  • Arrays and ArrayLists of supported types

Important Limitation: Bundles have a size limit (typically around 500KB to 1MB). Don’t try to save large images, videos, or extensive datasets. For large data, use other persistence methods like databases or files.

Using ViewModel to Survive Configuration Changes

While onSaveInstanceState() handles Process Death in Android, ViewModels help with configuration changes like screen rotation. However, ViewModels alone don’t survive process death.

Here’s how to combine both approaches:

Kotlin
class UserProfileViewModel : ViewModel() {
    
    // This survives configuration changes but NOT process death
    var userName = MutableLiveData<String>()
    var userAge = MutableLiveData<Int>()
    var profileImageUrl = MutableLiveData<String>()
    
    fun updateUserData(name: String, age: Int, imageUrl: String) {
        userName.value = name
        userAge.value = age
        profileImageUrl.value = imageUrl
    }
}

class UserProfileActivity : AppCompatActivity() {
    
    private lateinit var viewModel: UserProfileViewModel
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_user_profile)
        
        viewModel = ViewModelProvider(this).get(UserProfileViewModel::class.java)
        
        // If recovering from process death, restore to ViewModel
        savedInstanceState?.let {
            val name = it.getString("USER_NAME", "")
            val age = it.getInt("USER_AGE", 0)
            val imageUrl = it.getString("PROFILE_IMAGE_URL", "")
            
            viewModel.updateUserData(name, age, imageUrl)
        }
        
        observeViewModel()
    }
    
    override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)
        
        // Save ViewModel data to survive process death
        outState.putString("USER_NAME", viewModel.userName.value ?: "")
        outState.putInt("USER_AGE", viewModel.userAge.value ?: 0)
        outState.putString("PROFILE_IMAGE_URL", viewModel.profileImageUrl.value ?: "")
    }
    
    private fun observeViewModel() {
        viewModel.userName.observe(this) { name ->
            findViewById<TextView>(R.id.nameText).text = name
        }
        
        viewModel.userAge.observe(this) { age ->
            findViewById<TextView>(R.id.ageText).text = "Age: $age"
        }
    }
}

The ViewModel holds our UI data and survives configuration changes automatically. However, to survive Process Death in Android, we still need to:

  1. Save ViewModel data in onSaveInstanceState()
  2. Restore that data back to the ViewModel in onCreate()

This gives us the best of both worlds: automatic configuration change handling from ViewModel, plus process death recovery from saved instance state.

SavedStateHandle: The Modern Approach

Android Jetpack provides SavedStateHandle, which combines ViewModel benefits with automatic state saving. This is the recommended approach for handling Process Death in Android:

Kotlin
class ShoppingViewModel(private val savedStateHandle: SavedStateHandle) : ViewModel() {
    
    // Automatically saved and restored across process death
    var cartItems: MutableLiveData<List<String>> = savedStateHandle.getLiveData("cart_items", emptyList())
    var totalPrice: MutableLiveData<Double> = savedStateHandle.getLiveData("total_price", 0.0)
    
    fun addItem(item: String, price: Double) {
        val currentItems = cartItems.value?.toMutableList() ?: mutableListOf()
        currentItems.add(item)
        cartItems.value = currentItems
        
        val currentTotal = totalPrice.value ?: 0.0
        totalPrice.value = currentTotal + price
        
        // Automatically saved to SavedStateHandle
    }
    
    fun clearCart() {
        cartItems.value = emptyList()
        totalPrice.value = 0.0
    }
}


class ShoppingActivity : AppCompatActivity() {
    
    private val viewModel: ShoppingViewModel by viewModels()
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_shopping)
        
        // No manual state restoration needed!
        // SavedStateHandle does it automatically
        
        viewModel.cartItems.observe(this) { items ->
            updateCartUI(items)
        }
        
        viewModel.totalPrice.observe(this) { total ->
            findViewById<TextView>(R.id.totalText).text = "Total: $$total"
        }
        
        findViewById<Button>(R.id.addButton).setOnClickListener {
            viewModel.addItem("Product ${System.currentTimeMillis()}", 29.99)
        }
    }
    
    private fun updateCartUI(items: List<String>) {
        // Update RecyclerView or ListView with items
    }
}

SavedStateHandle is magical for handling Process Death in Android. Here’s why:

  1. getLiveData(): This method creates LiveData that’s automatically backed by saved state. When process death occurs, the data is saved. When the process restarts, the data is restored automatically.
  2. No manual saving: Unlike the previous examples, we don’t need to override onSaveInstanceState(). The SavedStateHandle does it for us.
  3. Type-safe: We can store various types, and they’re automatically serialized and deserialized.

The by viewModels() delegate is a Kotlin property delegate that creates or retrieves the ViewModel with SavedStateHandle automatically injected.

Testing Process Death in Android

Testing is crucial to ensure your app handles Process Death in Android correctly. Here are practical ways to test:

Method 1: Developer Options

  1. Go to Settings → Developer Options
  2. Enable “Don’t keep activities”
  3. Navigate through your app, switching between activities
  4. Every time an activity goes to the background, it’s destroyed

Method 2: Using ADB Command

Force your app’s process to be killed using Android Debug Bridge:

adb shell am kill com.yourapp.package

Then return to your app from the recent apps menu.

Method 3: Memory Pressure Testing

Use Android Studio’s Profiler to simulate low memory conditions:

  1. Open Android Profiler
  2. Select Memory
  3. Click “Force garbage collection” multiple times
  4. Android may kill your app’s process naturally

Common Mistakes to Avoid

When dealing with Process Death in Android, developers often make these mistakes:

Mistake 1: Saving Large Objects

Kotlin
// DON'T DO THIS
override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putSerializable("LARGE_IMAGE", largeImageBitmap) // Too big!
}

Why it’s wrong: Bundles have size limits. Saving large objects causes TransactionTooLargeException.

Better approach: Save only a reference or ID, then reload the data from a persistent source.

Kotlin
// DO THIS INSTEAD
override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putString("IMAGE_URL", imageUrl) // Save URL, not bitmap
}

Mistake 2: Assuming ViewModel Survives Process Death

Kotlin
// INCORRECT ASSUMPTION
class MyActivity : AppCompatActivity() {
    private lateinit var viewModel: MyViewModel
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        viewModel = ViewModelProvider(this).get(MyViewModel::class.java)
        
        // Assuming viewModel.userData is always available after process death
        // This is WRONG - ViewModel doesn't survive process death without SavedStateHandle
    }
}

Fix: Use SavedStateHandle or manually save/restore ViewModel data.

Mistake 3: Not Testing Thoroughly

Many developers never test Process Death scenarios until users report bugs. Always enable “Don’t keep activities” during development.

Best Practices for Handling Process Death in Android

1. Use SavedStateHandle for Simple Data

For primitive types and small objects, SavedStateHandle is your best friend:

Kotlin
class MyViewModel(private val state: SavedStateHandle) : ViewModel() {
    val username: LiveData<String> = state.getLiveData("username", "")
    val score: LiveData<Int> = state.getLiveData("score", 0)
}

2. Persist Important Data to Database

For critical data that users can’t afford to lose, use Room database or other persistent storage:

Kotlin
class FormActivity : AppCompatActivity() {
    private lateinit var database: AppDatabase
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        database = Room.databaseBuilder(
            applicationContext,
            AppDatabase::class.java,
            "form-database"
        ).build()
        
        // Restore form from database if exists
        lifecycleScope.launch {
            val savedForm = database.formDao().getUnsubmittedForm()
            savedForm?.let { restoreForm(it) }
        }
    }
    
    override fun onPause() {
        super.onPause()
        // Save form to database when leaving activity
        lifecycleScope.launch {
            val formData = collectFormData()
            database.formDao().saveForm(formData)
        }
    }
}

3. Combine Multiple Approaches

Use the right tool for each type of data:

  • SavedStateHandle: UI state (scroll position, selected tab, form inputs)
  • ViewModel: Temporary runtime data that survives configuration changes
  • Database/SharedPreferences: Persistent user data
  • Memory cache: Easily re-fetchable data

4. Keep Bundles Small

Only save essential state information. Calculate or reload other data:

Kotlin
override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    
    // Save only IDs, not entire objects
    outState.putInt("SELECTED_ITEM_ID", selectedItem.id)
    outState.putString("SEARCH_QUERY", searchQuery)
    
    // Don't save the entire search results list
    // Reload it using the search query instead
}

Advanced: Handling Process Death with Compose

If you’re using Jetpack Compose, handling Process Death in Android looks a bit different:

Kotlin
@Composable
fun ShoppingCartScreen(viewModel: ShoppingViewModel = viewModel()) {
    
    val cartItems by viewModel.cartItems.observeAsState(emptyList())
    val totalPrice by viewModel.totalPrice.observeAsState(0.0)
    
    Column(modifier = Modifier.fillMaxSize().padding(16.dp)) {
        Text(
            text = "Shopping Cart",
            style = MaterialTheme.typography.h5
        )
        
        Spacer(modifier = Modifier.height(16.dp))
        
        LazyColumn(modifier = Modifier.weight(1f)) {
            items(cartItems) { item ->
                CartItemRow(item = item)
            }
        }
        
        Divider()
        
        Text(
            text = "Total: $${"%.2f".format(totalPrice)}",
            style = MaterialTheme.typography.h6,
            modifier = Modifier.padding(vertical = 16.dp)
        )
        
        Button(
            onClick = { viewModel.addItem("New Product", 29.99) },
            modifier = Modifier.fillMaxWidth()
        ) {
            Text("Add Item")
        }
    }
}

@Composable
fun CartItemRow(item: String) {
    Row(
        modifier = Modifier
            .fillMaxWidth()
            .padding(vertical = 8.dp),
        horizontalArrangement = Arrangement.SpaceBetween
    ) {
        Text(text = item)
        Text(text = "$29.99")
    }
}

With Compose, you still use ViewModel with SavedStateHandle. The difference is:

  1. observeAsState(): Converts LiveData from ViewModel into Compose State
  2. Automatic recomposition: When the ViewModel data changes (including after process death restoration), Compose automatically updates the UI
  3. No manual lifecycle management: Compose handles the observation lifecycle for you

The underlying Process Death handling still uses SavedStateHandle in the ViewModel, but the UI layer becomes much simpler.

Monitoring Process Death in Production

To understand how often Process Death in Android affects your users, implement analytics:

Kotlin
class AnalyticsHelper(private val context: Context) {
    
    fun trackProcessDeath(activityName: String) {
        // Log to your analytics service
        FirebaseAnalytics.getInstance(context).logEvent("process_death_recovery") {
            param("activity_name", activityName)
            param("timestamp", System.currentTimeMillis())
        }
    }
}

class MainActivity : AppCompatActivity() {
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        
        if (savedInstanceState != null) {
            AnalyticsHelper(this).trackProcessDeath("MainActivity")
        }
    }
}

This helps you understand:

  • How frequently users experience process death
  • Which activities are most affected
  • Whether users successfully recover their state

Conclusion

Process Death in Android is an essential concept every Android developer must master. It’s not just about preventing crashes — it’s about creating a seamless user experience that feels reliable and polished.

Remember these key takeaways:

For simple UI state: Use SavedStateHandle with ViewModel. It automatically handles Process Death in Android with minimal code.

For important user data: Persist to a database. Don’t rely solely on saved instance state for data users can’t afford to lose.

Always test: Enable “Don’t keep activities” during development. Test your app thoroughly by simulating process death scenarios.

Keep bundles small: Only save essential state information. Reload complex data when the activity restores.

By properly handling Process Death in Android, you’ll build apps that feel professional, reliable, and respectful of your users’ time and data. Your users might never know about the complexity you’ve handled behind the scenes — and that’s exactly the point.

Start implementing these patterns in your next project, and you’ll be amazed at how much more robust your apps become. 

Composition Over Inheritance

What Is Composition Over Inheritance? The Built-In Compose Way Explained

If you’ve been writing object-oriented code for a while, you’ve probably used inheritance a lot. It feels natural. You create a base class, extend it, override a few methods, and move on.

But as projects grow, inheritance often becomes hard to manage. Classes get tightly coupled. Changes ripple through the codebase. Small tweaks break unexpected things.

This is where Composition Over Inheritance comes in.

In this post, we’ll break down what Composition Over Inheritance really means, why it matters, and how it’s used naturally in modern Kotlin development, especially with Jetpack Compose. 

What Does “Composition Over Inheritance” Mean?

Composition Over Inheritance is a design principle that says:

Prefer building classes by combining smaller, reusable components instead of extending base classes.

In simpler terms:

  • Inheritance says “is a”
  • Composition says “has a”

Instead of forcing behavior through class hierarchies, you compose behavior by using other objects.

A Simple Real-World Example

Think of a smartphone.

A smartphone has a camera, battery, speaker, and screen.

It does not inherit from Camera, Battery, or Speaker.

That’s composition.

If you used inheritance here, the design would fall apart fast.

The Problem With Inheritance

Inheritance looks clean at first, but it comes with hidden costs.

Example Using Inheritance (Problematic)

Kotlin
open class Vehicle {
    open fun move() {
        println("Vehicle is moving")
    }
}

open class Car : Vehicle() {
    override fun move() {
        println("Car is driving")
    }
}

class ElectricCar : Car() {
    override fun move() {
        println("Electric car is driving silently")
    }
}

At first glance, this seems fine.

But now imagine:

  • You want a flying car
  • You want a boat-car
  • You want a self-driving electric truck

Your inheritance tree explodes.

Changes to Vehicle affect every subclass. You’re locked into decisions you made early, often before requirements were clear.

This is exactly what Composition Over Inheritance helps you avoid.

Composition Over Inheritance Explained With Kotlin

Let’s rewrite the same idea using composition.

Create Small, Focused Behaviors

Kotlin
interface Engine {
    fun move()
}
Kotlin
class GasEngine : Engine {
    override fun move() {
        println("Driving using gas engine")
    }
}
Kotlin
class ElectricEngine : Engine {
    override fun move() {
        println("Driving silently using electric engine")
    }
}

Each class has one clear responsibility.

Compose the Behavior

Kotlin
class Car(private val engine: Engine) {

    fun drive() {
        engine.move()
    }
}

Now the Car has an engine, instead of being forced into a rigid hierarchy.

Use It

Kotlin
fun main() {
    val electricCar = Car(ElectricEngine())
    electricCar.drive()

    val gasCar = Car(GasEngine())
    gasCar.drive()
}

Output:

Driving silently using electric engine
Driving using gas engine

This is Composition Over Inheritance in action.

Why Composition Over Inheritance Is Better

Here’s why modern Kotlin developers strongly prefer this approach.

1. Less Coupling

Your classes depend on interfaces, not concrete implementations.

2. Easier Changes

You can swap behaviors without rewriting class hierarchies.

3. Better Testability

You can inject fake or mock implementations easily.

4. Cleaner Code

Smaller classes. Clear responsibilities. Fewer surprises.

Composition Over Inheritance in Jetpack Compose

Jetpack Compose is built almost entirely on Composition Over Inheritance.

That’s not an accident.

Traditional UI (Inheritance-Heavy)

Kotlin
class CustomButton : Button {
    // override styles, behavior, states
}

This leads to rigid UI components that are hard to reuse.

Compose Way (Composition First)

Kotlin
@Composable
fun MyButton(
    text: String,
    onClick: () -> Unit
) {
    Button(onClick = onClick) {
        Text(text)
    }
}

Here’s what’s happening:

  • MyButton is not extending Button
  • It uses Button
  • Behavior is passed in, not inherited

This is Composition Over Inheritance at the UI level.

Why Compose Feels Easier to Work With

Compose avoids deep inheritance trees entirely.

Instead:

  • UI is built from small composable functions
  • Each function does one thing
  • You combine them like building blocks

That’s composition by design.

Delegation: Kotlin’s Built-In Support for Composition

Kotlin makes Composition Over Inheritance even easier with delegation.

Example Using Delegation

Kotlin
interface Logger {
    fun log(message: String)
}

class ConsoleLogger : Logger {
    override fun log(message: String) {
        println(message)
    }
}

class UserService(private val logger: Logger) : Logger by logger

Now UserService automatically uses ConsoleLogger’s implementation without inheritance.

This keeps your code flexible and clean.

When Should You Still Use Inheritance?

Inheritance is not evil. It’s just often overused.

Inheritance works best when:

  • There is a true “is-a” relationship
  • The base class is stable
  • You control both parent and child classes

If those conditions are missing, Composition Over Inheritance is usually the safer choice.

Conclusion

Let’s wrap it up.

  • Composition Over Inheritance means building behavior using objects, not class hierarchies
  • Kotlin makes composition easy with interfaces and delegation
  • Jetpack Compose is a real-world example of this principle done right
  • Composition leads to flexible, testable, and maintainable code

If you’re writing Kotlin today, especially with Compose, you’re already using Composition Over Inheritance whether you realized it or not.

And once you start designing with it intentionally, your code gets simpler, not harder.

Architecting Alarms & Notifications in Android

Architecting Alarms & Notifications in Android: The Clean Architecture Way

Alarms, reminders, and notifications are some of the most deceptively complex features in Android development.

On the surface, they look simple: “Schedule something at a time and show a notification.”

In reality, you’re fighting with:

  • Doze mode
  • OEM background restrictions
  • Process death
  • App restarts
  • Device reboots
  • Android 12+ background execution limits
  • Android 13+ notification permissions
  • Android 14+ stricter alarms policies

After more than a decade building Android apps at scale, one thing is clear:

Most alarm and notification bugs are architectural bugs, not API bugs.

This article walks through how to architect alarms and notifications in a real production app using MVVM + Clean Architecture, feature modules, and a hybrid AlarmManager + WorkManager approach that survives modern Android constraints.

This is not theory. This is how you ship reliable reminder systems.

Core Architectural Principles (Hard-Earned Lessons)

Before talking about code, we need to align on principles. These are non-negotiable.

  1. Business logic must not depend on Android
  2. Scheduling is a domain concern, execution is an infrastructure concern
  3. Alarms wake the app, Workers do the work
  4. Repeating alarms are not repeating system alarms
  5. Everything must survive process death and reboot

If your current implementation violates any of these, instability is inevitable.

High-Level Architecture Overview

At a conceptual level, the flow looks like this:

Kotlin
UI → ViewModel → UseCase → Domain → Scheduler abstraction

                               Android implementation

                          AlarmManager → Receiver → Worker

                                Notification

Each arrow represents a boundary. Boundaries are what give us control.

Feature-Based Modular Architecture

In real apps, packages are not enough. Gradle modules matter.

Recommended Module Layout

Kotlin
:app

:core:domain
:core:data
:core:infra
:core:common

:feature:reminder
:feature:notification

Why This Matters

  • Domain becomes completely platform-independent
  • Feature modules own UI and presentation logic
  • Infra absorbs Android volatility
  • Teams can work independently without merge hell

Dependency Rules (Strict)

Kotlin
feature → domain
data → domain
infra → domain + data
app → everything

If a feature imports AlarmManager, your architecture is already compromised.

Domain Layer: Where Truth Lives

The domain layer is pure Kotlin. No Context. No Android imports.

Reminder Model

Kotlin
data class Reminder(
    val id: String,
    val triggerAtMillis: Long,
    val title: String,
    val message: String,
    val repeat: RepeatRule?
)

This model expresses intent, not implementation.

Repeat Rule Modeling (Critical Design)

Repeating reminders are the most common source of bugs. The fix starts here.

Kotlin
sealed class RepeatRule {
    data class Daily(val intervalDays: Int = 1) : RepeatRule()
    data class Weekly(val daysOfWeek: Set<DayOfWeek>) : RepeatRule()
    data class Interval(val millis: Long) : RepeatRule()
}

This gives us:

  • Explicit behavior
  • Full control
  • Deterministic scheduling

Scheduler Abstraction

The domain does not care how scheduling happens.

Kotlin
interface ReminderScheduler {
    fun schedule(reminder: Reminder)
    fun cancel(reminderId: String)
}

This single interface is what keeps Android chaos contained.

Use Case Example

Kotlin
class ScheduleReminderUseCase(
    private val repository: ReminderRepository,
    private val scheduler: ReminderScheduler
) {
    suspend operator fun invoke(reminder: Reminder) {
        repository.save(reminder)
        scheduler.schedule(reminder)
    }
}

Notice the order:

  1. Persist
  2. Schedule

That one decision is the difference between recoverable and broken reminders.

Presentation Layer (MVVM Done Properly)

The ViewModel knows nothing about alarms or notifications.

Kotlin
class ReminderViewModel(
    private val scheduleReminder: ScheduleReminderUseCase
) : ViewModel() {

   fun schedule(time: Long, title: String) {
        viewModelScope.launch {
            scheduleReminder(
                Reminder(
                    id = UUID.randomUUID().toString(),
                    triggerAtMillis = time,
                    title = title,
                    message = "Reminder",
                    repeat = null
                )
            )
        }
    }
}

This is clean, testable, and boring — exactly how ViewModels should be.

Infrastructure Layer: Where Android Lives

This is the layer that absorbs:

  • AlarmManager
  • PendingIntent
  • BroadcastReceiver
  • WorkManager
  • Notifications

And keeps them out of your business logic.

Alarm Scheduling Implementation

Kotlin
class AndroidReminderScheduler(
    private val alarmManager: AlarmManager,
    private val pendingIntentFactory: ReminderPendingIntentFactory
) : ReminderScheduler {

    override fun schedule(reminder: Reminder) {
        alarmManager.setExactAndAllowWhileIdle(
            AlarmManager.RTC_WAKEUP,
            reminder.triggerAtMillis,
            pendingIntentFactory.create(reminder.id)
        )
    }

    override fun cancel(reminderId: String) {
        alarmManager.cancel(
            pendingIntentFactory.create(reminderId)
        )
    }
}

We use:

  • setExactAndAllowWhileIdle
  • Explicit PendingIntent
  • One alarm per reminder

Anything else is unreliable.

PendingIntent Factory (Often Overlooked)

Kotlin
class ReminderPendingIntentFactory(
    private val context: Context
) {
    fun create(id: String): PendingIntent {
        val intent = Intent(context, ReminderAlarmReceiver::class.java)
            .putExtra("REMINDER_ID", id)

        return PendingIntent.getBroadcast(
            context,
            id.hashCode(),
            intent,
            PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE
        )
    }
}

Correct requestCode usage is essential for cancellation and updates.

Alarm Receiver: Do Almost Nothing

Kotlin
class ReminderAlarmReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val work = OneTimeWorkRequestBuilder<ReminderWorker>()
            .setInputData(workDataOf(
                "REMINDER_ID" to intent.getStringExtra("REMINDER_ID")
            ))
            .build()

        WorkManager.getInstance(context).enqueue(work)
    }
}

Receivers should delegate immediately. Anything else risks ANRs.

Worker: The Real Execution Engine

This is where notifications are shown and repeats are handled.

Kotlin
@HiltWorker
class ReminderWorker @AssistedInject constructor(
    @Assisted context: Context,
    @Assisted params: WorkerParameters,
    private val repository: ReminderRepository,
    private val scheduler: ReminderScheduler,
    private val calculator: NextTriggerCalculator
) : CoroutineWorker(context, params) {

     override suspend fun doWork(): Result {
        val id = inputData.getString("REMINDER_ID") ?: return Result.failure()
        val reminder = repository.getById(id) ?: return Result.failure()
        showNotification(reminder)
        reminder.repeat?.let {
            val next = calculator.calculate(reminder.triggerAtMillis, it)
            val updated = reminder.copy(triggerAtMillis = next)
            repository.save(updated)
            scheduler.schedule(updated)
        }
        return Result.success()
    }
}

This explicit rescheduling is what makes repeating reminders reliable.

Why Repeating Alarms Must Be Manual

Using setRepeating():

  • Is inexact
  • Breaks under Doze
  • Is ignored by OEMs
  • Cannot adapt dynamically

One alarm → one execution → reschedule next

This model survives every Android version.

Hilt Dependency Injection (Exact Bindings)

Scheduler Binding

Kotlin
@Module
@InstallIn(SingletonComponent::class)
object SchedulerModule {

    @Provides
    fun provideReminderScheduler(
        alarmManager: AlarmManager,
        factory: ReminderPendingIntentFactory
    ): ReminderScheduler =
        AndroidReminderScheduler(alarmManager, factory)
}

AlarmManager Binding

Kotlin
@Module
@InstallIn(SingletonComponent::class)
object SystemServiceModule {

    @Provides
    fun provideAlarmManager(
        @ApplicationContext context: Context
    ): AlarmManager =
        context.getSystemService(Context.ALARM_SERVICE) as AlarmManager
}

Domain remains DI-agnostic.

AlarmManager vs WorkManager: The Real Decision Matrix

RequirementAlarmManagerWorkManager
Exact timingProvides precise, exact-time execution and is suitable for alarms and reminders that must fire at a specific momentDoes not guarantee exact timing; execution can be delayed based on system conditions
Doze compatibilityCan fire during Doze mode only when using exact alarms with allow-while-idle, and even then execution is constrainedDoes not run during Doze at an exact time and may be deferred until the system exits idle mode
Long background workNot suitable for long-running background tasks; execution time must be very shortDesigned specifically for longer background work with proper lifecycle handling
Survives device rebootDoes not automatically survive a device reboot and requires manual reschedulingAutomatically survives device reboot and restores scheduled work
Battery efficiencyLess battery efficient because it bypasses system optimizations for exact timingMore battery efficient because it respects system scheduling and optimization policies
User-visible alertsWell suited for user-visible actions such as alarms, reminders, and time-critical notificationsLess reliable for user-visible alerts that must appear at an exact time
  • Use AlarmManager when the user expects something to happen at an exact moment, such as reminders, alarms, or medication alerts.
  • Use WorkManager when the task involves background processing, network calls, database work, or any operation that does not require exact timing.
  • Combine both for production-grade systems: let AlarmManager wake the app, and let WorkManager perform the actual work.

The Correct Hybrid Approach

  1. AlarmManager wakes the app at the exact time
  2. WorkManager executes background work
  3. Worker shows notification and reschedules

This combination works across:

  • Android 8 → 15
  • OEM restrictions
  • Play Store policies

Conclusion

Reliable alarms and notifications are not about clever tricks or undocumented APIs. They are about respecting architectural boundaries and accepting Android’s reality.

If you:

  • Keep domain pure
  • Treat scheduling as a business concern
  • Let infra absorb platform volatility
  • Reschedule explicitly

Your reminder system will survive every Android release.

And you’ll sleep better knowing your users won’t miss their alarms.

Factory Pattern Simplify Complex Object Creation

How Does the Factory Pattern Simplify Complex Object Creation in Modern Applications?

Creating objects sounds simple at first. You call a constructor, pass a few values, and move on.

But as applications grow, object creation often becomes messy.

You start seeing:

  • Too many if-else or when blocks
  • Classes tightly coupled to concrete implementations
  • Code that’s hard to test, extend, or understand

This is exactly where the Factory Pattern Simplify Complex Object Creation problem in modern applications.

Let’s break it down in a clear and practical way.

What Is the Factory Pattern?

The Factory Pattern is a creational design pattern that handles object creation for you.

Instead of creating objects directly using constructors, you delegate that responsibility to a factory.

In simple terms:

A factory decides which object to create and how to create it.

Your main code just asks for an object and uses it. It doesn’t care about the details.

This separation is what makes the Factory Pattern Simplify Complex Object Creation so effective.

Why Object Creation Becomes Complex

In real-world applications, object creation often depends on:

  • User input
  • Configuration files
  • API responses
  • Environment (development, testing, production)

Example without a factory:

Kotlin
val paymentProcessor = when (paymentType) {
    "CARD" -> CardPaymentProcessor()
    "UPI" -> UpiPaymentProcessor()
    "WALLET" -> WalletPaymentProcessor()
    else -> throw IllegalArgumentException("Invalid payment type")
}

Now imagine this logic repeated across multiple files.

Problems appear quickly:

  • Code duplication
  • Hard-to-maintain logic
  • Difficult testing
  • Violations of the Single Responsibility Principle

This is why developers rely on patterns that simplify complex object creation.

How the Factory Pattern Helps

The Factory Pattern solves these issues by:

  • Centralizing object creation
  • Reducing tight coupling
  • Making code easier to extend
  • Improving testability

Most importantly, it lets your business logic focus on what to do, not how objects are created.

That’s the real power behind Factory Pattern Simplify Complex Object Creation.

A Simple Kotlin Example

Define a Common Interface

Kotlin
interface Notification {
    fun send(message: String)
}

This interface represents a notification system.

Create Concrete Implementations

Kotlin
class EmailNotification : Notification {
    override fun send(message: String) {
        println("Sending Email: $message")
    }
}

class SmsNotification : Notification {
    override fun send(message: String) {
        println("Sending SMS: $message")
    }
}

class PushNotification : Notification {
    override fun send(message: String) {
        println("Sending Push Notification: $message")
    }
}

Each class has its own behavior but follows the same contract.

Create the Factory

Kotlin
object NotificationFactory {

    fun create(type: String): Notification {
        return when (type.uppercase()) {
            "EMAIL" -> EmailNotification()
            "SMS" -> SmsNotification()
            "PUSH" -> PushNotification()
            else -> throw IllegalArgumentException("Unknown notification type")
        }
    }
}

This is the heart of the Factory Pattern.

The factory:

  • Knows which object to create
  • Hides creation logic from the rest of the app

Use the Factory

Kotlin
val notification = NotificationFactory.create("EMAIL")
notification.send("Welcome to our platform!")

That’s it.

The calling code:

  • Does not know about concrete classes
  • Does not change if new notification types are added

This is how the Factory Pattern Simplify Complex Object Creation in Kotlin applications.

Why Kotlin Works So Well with Factory Pattern

Kotlin makes the Factory Pattern even cleaner because of:

  • object keyword for singletons
  • when expressions
  • Strong type safety
  • Concise syntax

Factories in Kotlin are:

  • Easy to read
  • Hard to misuse
  • Simple to test

This makes Kotlin a great fit for modern, scalable architecture.

Real-World Use Cases

You’ll see the Factory Pattern used in:

  • Database connection creation
  • Payment gateways
  • Logging frameworks
  • UI component generation
  • API client creation

Anywhere object creation depends on conditions, the Factory Pattern Simplify Complex Object Creation effectively.

Factory Pattern and Clean Architecture

From an architectural perspective, the Factory Pattern supports:

  • Loose coupling
  • Open/Closed Principle
  • Single Responsibility Principle

Your system becomes:

  • Easier to extend
  • Safer to modify
  • More readable for new developers

Common Mistakes to Avoid

Even with factories, mistakes happen.

Avoid:

  • Putting business logic inside the factory
  • Creating overly complex factories
  • Ignoring interfaces

A factory should only create objects, nothing more.

When Should You Use the Factory Pattern?

Use it when:

  • Object creation logic is complex
  • You expect future extensions
  • You want cleaner, testable code

Avoid it for:

  • Very small or one-off objects
  • Simple scripts

Conclusion

The Factory Pattern Simplify Complex Object Creation by separating object creation from object usage.

It keeps your code:

  • Clean
  • Flexible
  • Easy to maintain

In modern Kotlin applications, this pattern is not just useful. It’s often essential.

If you’re building scalable systems, learning and applying the Factory Pattern is a smart investment in code quality and long-term success.

Use Case Patterns

Mastering Use Case Patterns: A Practical Guide for Modern Software Design

Modern software design isn’t just about writing code that works; it’s about writing code that’s maintainable, scalable, and easy to understand. One way to achieve this is by using Use Case Patterns — a structured approach to modeling software functionality based on real-world user interactions. In this guide, we’ll break down everything you need to know about use case patterns, provide practical Kotlin examples, and show how to apply them effectively in your projects.

What Are Use Case Patterns?

A use case pattern is a reusable template that describes how a system should respond to specific user actions or events. Think of them as building blocks for designing your software’s functionality. Instead of starting from scratch each time, you can rely on patterns to standardize workflows, reduce errors, and speed up development.

For example, common use case patterns include:

  • Authentication — logging in and out
  • CRUD Operations — create, read, update, delete
  • Notification Handling — sending emails or push notifications

These patterns provide a blueprint for solving recurring problems, making your code more predictable and maintainable.

Why Use Use Case Patterns in Modern Software Design?

  1. Consistency: Patterns ensure that similar functionalities follow a consistent approach across your project.
  2. Reusability: Once you define a pattern, you can reuse it in multiple parts of your app without rewriting code.
  3. Clarity: Clear use case patterns make it easier for new developers to understand your system.
  4. Scalability: Patterns help design systems that can grow without becoming messy or unmanageable.

Core Principles of Use Case Patterns

To master use case patterns, keep these principles in mind:

  • Single Responsibility: Each pattern should handle one type of use case.
  • Clear Actors: Define who or what interacts with the system.
  • Explicit Steps: Document each step the system performs in response to an action.
  • Reusability: Design patterns so they can be applied in multiple scenarios.

Implementing Use Case Patterns in Kotlin

Kotlin is a modern, concise programming language that’s perfect for demonstrating use case patterns. Let’s go through a simple example: a user registration system.

Define the Use Case Interface

Start by creating an interface that represents the use case:

Kotlin
interface UseCase<in Input, out Output> {
    fun execute(input: Input): Output
}

Here’s what’s happening:

  • Input is the data the use case needs (e.g., user info).
  • Output is the result of executing the use case (e.g., success or error).
  • execute() is the method that contains the business logic.

Implement a Specific Use Case

Now, let’s implement a RegisterUserUseCase:

Kotlin
data class User(val username: String, val email: String, val password: String)

class RegisterUserUseCase : UseCase<User, Boolean> {
    override fun execute(input: User): Boolean {
        if (input.username.isEmpty() || input.email.isEmpty() || input.password.isEmpty()) {
            return false
        }
        println("User ${input.username} registered successfully!")
        return true
    }
}

Here,

  • The User data class holds user information.
  • RegisterUserUseCase implements the UseCase interface.
  • The execute method checks for valid input and prints a success message.
  • Returning true or false indicates whether the registration was successful.

Use the Use Case

Finally, use the pattern in your application:

Kotlin
fun main() {
    val registerUseCase = RegisterUserUseCase()
    val newUser = User("amol", "[email protected]", "password123")

    val isRegistered = registerUseCase.execute(newUser)
    println("Registration status: $isRegistered")
}

This simple example shows how use case patterns create a clear, reusable structure. You can now create other use cases, like LoginUserUseCase, following the same template.

Best Practices for Use Case Patterns

  1. Keep Use Cases Small: Avoid overloading a single use case with too many responsibilities.
  2. Focus on Business Logic: Use case patterns should contain only business logic — not UI or database code.
  3. Combine With Repositories: Use repositories or services for data access while keeping the use case focused.
  4. Document Clearly: Add descriptions for each use case to improve maintainability.

Advanced Tip: Chaining Use Cases

Sometimes, a single user action involves multiple steps. Kotlin’s flexibility allows chaining use cases:

Kotlin
class CompleteUserOnboardingUseCase(
    private val registerUserUseCase: RegisterUserUseCase,
    private val sendWelcomeEmailUseCase: SendWelcomeEmailUseCase
) : UseCase<User, Boolean> {
    override fun execute(input: User): Boolean {
        val registered = registerUserUseCase.execute(input)
        if (!registered) return false
        sendWelcomeEmailUseCase.execute(input)
        return true
    }
}

Here, the CompleteUserOnboardingUseCase combines registration and email notification, keeping each use case modular and reusable.

Conclusion

Mastering use case patterns is a game-changer for modern software design. They help you write cleaner, maintainable code that is easy to understand and scale. Using Kotlin, you can implement these patterns with minimal boilerplate, keeping your focus on business logic.

Start small, focus on clarity, and gradually build a library of reusable patterns. Before long, your software architecture will be robust, consistent, and much easier to maintain.

By embracing use case patterns, you not only improve your code today — you future-proof your projects for tomorrow.

Repository Pattern

How the Repository Pattern Makes Code Easier to Test, Maintain, and Scale

Software projects rarely stay small. Features grow, requirements change, and teams expand. When data access logic is tightly coupled with business logic, even a simple update can break multiple parts of the system.

This is where the Repository Pattern becomes extremely valuable.

In this blog, we’ll explain the Repository Pattern in a clear and beginner-friendly way using Kotlin examples. You’ll learn what it is, why it matters, and how it makes your code easier to test, maintain, and scale over time.

What Is the Repository Pattern?

The Repository Pattern is a design pattern that separates data access logic from business logic.

Instead of letting your services or view models talk directly to a database, API, or data source, all data operations are handled by a repository. Your business logic interacts only with the repository interface.

You can think of the repository as a middle layer that hides all the details of how data is stored or retrieved.

This separation leads to cleaner, safer, and more flexible code.

Why the Repository Pattern Is Important

Without the Repository Pattern, applications often suffer from:

  • Database queries scattered across the codebase
  • Business logic tightly tied to a specific database or framework
  • Difficult and slow unit testing
  • High risk when changing data sources

The Repository Pattern solves these problems by creating a single, consistent place for data access.

Core Structure of the Repository Pattern

A typical Repository Pattern implementation includes:

  1. A repository interface that defines allowed operations
  2. A repository implementation that handles actual data access
  3. Business logic that depends only on the interface

Let’s walk through a simple Kotlin example.

Repository Pattern in Kotlin

Step 1: Define a Data Model

Kotlin
data class User(
    val id: Int,
    val name: String
)

This is a simple data class that represents a user in the system.

Step 2: Create the Repository Interface

Kotlin
interface UserRepository {
    fun getById(id: Int): User?
    fun getAll(): List<User>
    fun add(user: User)
}

This interface defines what the application can do with user data. It does not care how or where the data is stored.

Step 3: Implement the Repository

Kotlin
class UserRepositoryImpl(private val database: UserDatabase) : UserRepository {

    override fun getById(id: Int): User? {
        return database.users.find { it.id == id }
    }

    override fun getAll(): List<User> {
        return database.users
    }

    override fun add(user: User) {
        database.users.add(user)
    }
}

This class contains all the data access logic. Whether the data comes from Room, SQL, an API, or another source, the rest of the app does not need to know.

Step 4: Use the Repository in Business Logic

Kotlin
class UserService(
    private val userRepository: UserRepository
) {
    fun registerUser(user: User) {
        userRepository.add(user)
    }
}

The service depends on the repository interface, not the implementation. This design choice is key to flexibility and testability.

How the Repository Pattern Improves Testability

Testing becomes much easier with the Repository Pattern because dependencies can be replaced with fake or mock implementations.

Fake Repository for Testing

Kotlin
class FakeUserRepository : UserRepository {
    private val users = mutableListOf<User>()

    override fun getById(id: Int): User? {
        return users.find { it.id == id }
    }

    override fun getAll(): List<User> {
        return users
    }

    override fun add(user: User) {
        users.add(user)
    }
}

You can now test your service without a real database:

Kotlin
val repository = FakeUserRepository()
val service = UserService(repository)

service.registerUser(User(1, "Amol"))

This approach results in faster, more reliable tests and supports accurate, verifiable behavior.

How the Repository Pattern Improves Maintainability

As applications grow, maintainability becomes more important than short-term speed.

The Repository Pattern helps by:

  • Keeping data logic in one place
  • Reducing duplicated queries
  • Making code easier to read and reason about
  • Allowing safe refactoring

If you need to update how users are stored or retrieved, you only change the repository implementation.

How the Repository Pattern Helps with Scalability

Scalability is about more than performance. It’s also about adapting to future changes.

With the Repository Pattern, you can:

  • Add caching inside the repository
  • Switch databases or APIs
  • Introduce pagination or background syncing

For example, you might later enhance this:

Kotlin
override fun getAll(): List<User> {
    return database.users
}

Without changing any business logic that depends on it.

Common Mistakes to Avoid

When using the Repository Pattern, avoid these pitfalls:

  • Putting business logic inside repositories
  • Exposing database-specific models directly
  • Adding unnecessary abstraction to very small projects

The Repository Pattern should simplify your code, not complicate it.

When Should You Use the Repository Pattern?

The Repository Pattern is a great choice when:

  • Your app has complex business rules
  • You expect data sources to evolve
  • You want clean unit tests
  • Your project is designed for long-term growth

For quick prototypes, it may be unnecessary. For production systems, it’s often worth the investment.

Conclusion

The Repository Pattern helps you write code that is easier to test, easier to maintain, and easier to scale.

By separating data access from business logic, you create a cleaner architecture that supports growth and change.

When implemented correctly in Kotlin, the Repository Pattern leads to reliable, readable, and future-proof applications that developers can trust.

error: Content is protected !!