Home on Chanzmao ʕ•ᴥ•ʔ Bear Blog

View and State Separation Is No Longer the Main Story in Jetpack Compose

Tue, 28 Jul 2026 05:37:51 +0900

For years, Android developers learned the same architectural principle:

Separate the View from the State.

In the XML View system, this was essential.

The View was mutable. Updating the UI meant calling methods like setText(), setVisibility(), or notifyDataSetChanged(). As applications grew, mixing UI updates with business logic quickly became difficult to maintain.

State
  |
ViewModel
  |
View (XML)

This architecture made sense because the View itself owned a large part of the UI state.

Navigation 3: Does ViewModel Still Need to Be a State Holder?

Sun, 26 Jul 2026 08:29:50 +0900

Compose and Navigation 3 are changing what ViewModel is responsible for.

For years, Android developers followed one simple rule:

Put your screen state into a ViewModel.

It wasn’t just a recommendation—it was one of the foundations of Android architecture.

A ViewModel survived configuration changes, SavedStateHandle helped restore state after process death, and Activities and Fragments no longer needed to worry about holding screen state themselves.

As a result, ViewModel naturally became the home for almost every piece of screen state.

Navigation 3 Navigation Graph Patterns

Fri, 24 Jul 2026 08:59:12 +0900

Extension Functions, Sealed NavKeys, and Nested NavDisplay

Navigation 3 no longer uses nested navigation graphs like navigation() in the old Navigation Component.

Instead, you organize screens using one of these three patterns.

1. Group entries with extension functions

Split screen definitions by feature or module.

// AuthModule.kt
fun EntryProviderScope<NavKey>.authGraph() {
    entry<Login> { LoginScreen() }
    entry<SignUp> { SignUpScreen() }
}

// AppNavigation.kt
val entryProvider = entryProvider {
    authGraph()
    entry<Home> { HomeScreen() }
}

NavDisplay(
    backStack = backStack,
    entryProvider = entryProvider
)

This keeps navigation definitions modular while sharing a single NavBackStack.

Understanding dropUnlessResumed: Preventing Double Navigation in Navigation 3

Wed, 22 Jul 2026 12:39:48 +0900

When using Navigation 3, navigating to another screen is as simple as updating the NavBackStack.

For example:

Button(
    onClick = {
        backStack.add(Detail())
    }
) {
    Text("Detail")
}

This looks perfectly fine, but there’s a subtle problem.

If the user taps the button twice in quick succession, backStack.add() may be called twice before the current screen finishes transitioning. As a result, the same destination can be added to the back stack multiple times.

Navigation 3: High-Level vs. Low-Level NavDisplay APIs

Mon, 20 Jul 2026 00:26:57 +0900

A practical comparison of NavDisplay(backStack) and NavDisplay(entries).

Why `NavDisplay(entries)` can preserve UI state across multiple NavBackStacks

Navigation 3 provides multiple ways to use NavDisplay.

For a single back stack, this is usually enough:

NavDisplay(
    backStack = backStack, 
    entryProvider = entryProvider { 
        // ... 
    } 
)

But when each tab has its own NavBackStack, the lower-level entries API gives us more control.

High-Level API: `NavDisplay(backStack)`

val homeBackStack = rememberNavBackStack(Home) 
val searchBackStack = rememberNavBackStack(Search) 
val currentBackStack = when (currentTab) { 
    Tab.Home -> homeBackStack 
    Tab.Search -> searchBackStack
} 

NavDisplay( 
    backStack = currentBackStack, 
    entryProvider = entryProvider { 
        // ... 
    } 
)

This is simple and often all you need.

Stop Passing Everything Down the Compose Tree: 4 Ways to Eliminate Prop Drilling

Fri, 10 Jul 2026 03:24:04 +0900

From Slot APIs to scoped ViewModels, here are four Compose patterns that keep deeply nested UI trees clean and maintainable.

Jetpack Compose encourages building UIs from small, reusable composables. As an application grows, however, those composables naturally become deeply nested.

A common consequence is prop drilling: passing the same data or callbacks through multiple intermediate composables that don’t actually use them.

Parent
  ↓
Root
  ↓
Content
  ↓
Card
  ↓
UserName

In this example, Root, Content, and Card simply forward parameters to UserName. They don’t consume the data themselves—they merely act as relays.

Keep UI-Only Logic in the UI with snapshotFlow

Mon, 06 Jul 2026 22:33:31 +0900

Not every piece of UI state belongs in your ViewModel. Scroll position, selection, and other UI-only state can stay in the UI. snapshotFlow lets you react to those changes while keeping your architecture simple and idiomatic.

When working with Jetpack Compose, it’s easy to fall into the habit of sending every state change to the ViewModel.

For example:

Scroll position
The currently visible item
The selected tab
TextField input
Whether a FAB should be visible

But does your ViewModel really need to know about all of these?

Stop Guessing When to Restore Scroll Position in Compose

Mon, 22 Jun 2026 21:54:12 +0900

Restoring a scroll position in Jetpack Compose looks simple at first.

val gridState = rememberLazyStaggeredGridState(
    initialFirstVisibleItemIndex = savedIndex, 
    initialFirstVisibleItemScrollOffset = savedOffset
)

However, this approach only works if the items have already been laid out. When your data is loaded asynchronously, the grid often starts with zero items, so the initial scroll position is ignored.

Many developers try to solve this by calling scrollToItem() inside a LaunchedEffect, but there’s another problem:

SavedStateHandle in the Navigation 3 Era

Thu, 18 Jun 2026 08:30:04 +0900

With Navigation 3, the role of SavedStateHandle has become much clearer.

Use NavKey for navigation and screen arguments.

Use ViewModel for normal UI state management.

Use SavedStateHandle only for lightweight UI state that should survive process death.

Responsibilities

NavKey
  -> Navigation and screen arguments

ViewModel
  -> Regular UI state
  -> Survives configuration changes

SavedStateHandle
  -> Lightweight state restored after process death

A common mistake is putting everything into SavedStateHandle.

When Should You Use snapshotFlow in Jetpack Compose?

Mon, 15 Jun 2026 04:21:15 +0900

Jetpack Compose provides several ways to react to state changes. Among them, snapshotFlow is often misunderstood.

Many developers either overuse it or never use it at all.

The key idea is simple:

Use snapshotFlow when you need to convert Compose state into a Kotlin Flow and perform side effects.

If you’re only updating the UI, snapshotFlow is usually the wrong tool.

What snapshotFlow Actually Does

snapshotFlow observes Compose state and emits new values as a Flow whenever that state changes.

Two Simple ADB Commands for Android State Restoration Testing

Sat, 13 Jun 2026 09:09:36 +0900

When building Android apps, I frequently test two scenarios:

Configuration Changes
Process Death

Both affect UI state, but they exercise different parts of your app.

Testing Configuration Changes

A configuration change recreates the Activity while keeping the process alive. Typical examples include screen rotation, locale changes, and font scale changes.

The following command rotates the device to landscape, then back to portrait:

# Disable auto-rotation so the device stays in a fixed orientation
adb shell settings put system accelerometer_rotation 0 && \

# Rotate the device to landscape (Configuration Change occurs)
adb shell settings put system user_rotation 1 && \

# Wait for Activity recreation to complete
sleep 1 && \

# Rotate the device back to portrait (another Configuration Change)
adb shell settings put system user_rotation 0 && \

# Re-enable auto-rotation
adb shell settings put system accelerometer_rotation 1

Expected behavior:

Kotlin Generic Type Declarations: Common Patterns and Examples

Wed, 10 Jun 2026 00:00:20 +0900

Generics <T> allow you to write reusable, type-safe code without committing to a specific type upfront.

They’re commonly used in collections, classes, functions, interfaces, and function types throughout Kotlin.

This article walks through some of the most common generic type declaration patterns you’ll encounter in real-world Kotlin code.

List

Specify the type of elements stored in a list.

val names: List<String> = listOf("Alice", "Bob")

Only String values can be stored in this list.

Kotlin 2.4 Collection Literals and Type Inference

Mon, 08 Jun 2026 10:46:24 +0900

Kotlin 2.4 introduces experimental support for collection literals, allowing collections to be created using square brackets.

Experimental Support for collection literals

Support for collection literals Kotlin 2.4.0 introduces experimental support for collection literals. You can now create collections in a simpler and more concise way using brackets [].

https://kotlinlang.org/docs/whatsnew24.html#support-for-collection-literals

kotlin {
    jvmToolchain(21)
    compilerOptions {
         freeCompilerArgs.add("-Xcollection-literals")
    }
}

Let’s compare the inferred types of several common collection APIs.

val names = mutableListOf("Joe", "Alice")
// MutableList<String>

val names = listOf("Joe", "Alice")
// List<String>

val names = listOf("Joe", "Alice").toMutableList()
// MutableList<String>

val names = arrayOf("Joe", "Alice")
// Array<String>

With collection literals enabled:

Who Owns Your ViewModel? Lifetime, Scope, and the Three Owners in Navigation 3

Sat, 06 Jun 2026 13:00:34 +0900

Choosing a ViewModel scope is really asking one question: when something dies, should the ViewModel die with it? Get that right and state flows naturally through your app. Get it wrong and you’re either losing state too early or holding onto it long after it’s useful.

In Navigation 2, this was mostly handled for you. In Navigation 3, you’re in charge — and the defaults changed in a way that will surprise you if you’re migrating from Navigation2.

Why Most Tech Blogs Die Fast

Sat, 06 Jun 2026 00:41:26 +0900

Let’s be honest for a second: the shelf life of a technical blog post is brutally short.

It’s an open secret in the dev community, but one we usually choose to ignore. Think about it. You spend an entire weekend fighting a bizarre configuration bug, finally figure it out, set up a flawless GitHub repo, and write up a beautiful step-by-step tutorial. Fast forward a year—sometimes just a few months—and that article is practically a ghost town, buried under a mountain of framework updates and new tools.

A Cleaner Way to Pass Navigation Arguments in Navigation 3

Fri, 05 Jun 2026 08:11:30 +0900

Recently I came across an interesting article about using Hilt Assisted Injection with Jetpack Navigation 3 instead of relying on SavedStateHandle for passing navigation arguments to a ViewModel.

The idea is simple: rather than having a ViewModel read navigation arguments from SavedStateHandle, pass the route object directly through Assisted Injection.

The Traditional Approach

For a long time, many Android apps have used SavedStateHandle to retrieve navigation arguments:

class DetailViewModel(
    savedStateHandle: SavedStateHandle
) : ViewModel() {

    private val route = savedStateHandle.toRoute<DetailRoute>()
}

This works well, but it also means the ViewModel knows about navigation-specific APIs.

Markdown Syntax Guide

Fri, 03 Jan 2020 00:00:00 +0000

For a quick cheatsheet, check out https://simplemde.com/markdown-guide.

This article offers a sample of basic Markdown syntax that can be used in Hugo content files, also it shows whether basic HTML elements are decorated with CSS in a Hugo theme.