DEV Community: Siddharth Pandalai

collectAsState is quietly leaking your work

Siddharth Pandalai — Fri, 04 Sep 2026 04:43:46 +0000

Here is a line you have written a hundred times:

val state by viewModel.data.collectAsState()

It looks harmless. It is the standard way to turn a Flow into Compose state. And on a screen with live data, it quietly keeps working long after the user has walked away.

The screen nobody is watching

collectAsState starts collecting the flow and stops only when the composable leaves the composition. That sounds right until you remember what backgrounding an app does, which is almost nothing to the composition. Send the app to the background and the composable is still composed. So the collection keeps running. The flow keeps emitting. Your ViewModel keeps fetching, computing, and pushing new state to a screen that is not on screen.

On a live price ticker or a location feed, that is real battery and mobile data spent in the dark. It is also a quiet source of bugs, because off-screen updates can pile up and then hit the user with a jump of stale changes the moment they return.

The one-word fix

val state by viewModel.data.collectAsStateWithLifecycle()

collectAsStateWithLifecycle ties the collection to the lifecycle owner. When the lifecycle drops below STARTED, it stops collecting. When it comes back, it resumes. If your upstream is a stateIn or shareIn flow with WhileSubscribed, the whole pipeline can now go cold while hidden and warm back up on return. Nobody pays for a screen that is not visible.

It lives in androidx.lifecycle.runtime.compose. Add the dependency, change the one call, and the leak is gone.

Make it the default

Treat collectAsStateWithLifecycle as the default and plain collectAsState as the exception. The rare time you actually want collection to continue while the screen is hidden should be a deliberate, commented decision, not something you got by reaching for the shorter name out of habit.

The takeaway

Lifecycle awareness is not a nice-to-have you bolt on later. It is the line between work that stops when the user leaves and work that runs forever in the background. The Recomposer does not mind an empty room. It will happily keep redrawing it. Your job is to turn the lights off when everyone goes home.

🌀 Iteration 6 of **The Loopdown. field notes from an engineer who writes.
Series: **Ghosts In The Recomposition* · Featuring: The Recomposer*
← Previously in this series: Your LazyColumn recomposes on every scroll
📚 The full series: Ghosts In The Recomposition

Follow the loop → LinkedIn · dev.to · GitHub

expect/actual is the wrong default in KMP

Siddharth Pandalai — Wed, 02 Sep 2026 05:41:21 +0000

Every Kotlin Multiplatform tutorial teaches expect/actual in the first ten minutes. It is the headline feature, the thing that makes KMP feel like magic. So new teams learn it first and then reach for it every single time common code needs to touch a platform.

That habit is how shared modules turn into a knot. expect/actual is a fine tool for a narrow job, and the wrong default for most of them.

What expect/actual actually is

It is a compile-time binding by name. You declare something in common:

// commonMain
expect class Clipboard() {
    fun copy(text: String)
}

and the compiler requires exactly one actual per platform:

// androidMain
actual class Clipboard actual constructor() {
    actual fun copy(text: String) { /* android impl */ }
}

The binding is fixed at build time. There is one actual for Android, one for iOS, and the compiler wires them in. That sounds convenient, and for the right case it is.

Where it hurts

The moment you want to do anything other than "one fixed body per platform," the weld gets in the way.

You cannot inject a fake. There is no test actual, so your common use case that depends on Clipboard cannot be tested in commonTest without inventing a whole extra source set to satisfy the compiler.
You cannot hold two implementations. No real one and a fake one, no A/B, no decorator. The compiler picks one per platform and that is that.
Your common code is coupled to platform declarations, one weld per concern, spread across storage, networking, clipboard, analytics, and everything else you reached for it with.

I lived this on PaymentsLab. Early common code used expect/actual for every platform seam. It compiled and shipped. Then I sat down to unit-test a payment use case in commonTest and simply could not, because the seams had no fakes.

The better default: an interface, injected

// commonMain
interface Clipboard {
    fun copy(text: String)
}

class CopyReceiptUseCase(private val clipboard: Clipboard) {
    fun run(receipt: Receipt) = clipboard.copy(receipt.asText())
}

Provide the real thing per platform, and hand it in through your DI graph (Koin, in our case):

// androidMain
class AndroidClipboard(private val ctx: Context) : Clipboard { /* ... */ }

// commonTest
class FakeClipboard : Clipboard {
    var last: String? = null
    override fun copy(text: String) { last = text }
}

@Test fun copies_receipt() {
    val fake = FakeClipboard()
    CopyReceiptUseCase(fake).run(receipt)
    assertEquals(expected, fake.last)
}

Same platform bodies. Same behavior. But now the common code depends on an interface it owns, not on a platform declaration, and it is testable in one line.

So when is expect/actual right?

For the small, fixed, one-per-platform joints where a stand-in makes no sense:

A typealias to a platform type (expect class Uuid, actualized to the platform's UUID).
A single top-level function with exactly one meaning per platform and nothing to test, like reading a platform constant.

Those are genuine welds. One joint, permanent, no reason to swap it.

The takeaway

The KMP question is rarely "how do I reach the platform." It is "what do I hand my common code." Hand it an interface it owns, and inject the platform body. Keep expect/actual for the handful of places you actually want a weld.

The Understudy is perfect for a small fixed role, cast by name, on stage every night. Just do not cast one for every part in the play.

🌀 Iteration 5 of **The Loopdown. field notes from an engineer who writes.
Series: **One Brain Two Bodies* · Featuring: The Understudy*
📚 The full series: One Brain Two Bodies

Follow the loop → LinkedIn · dev.to · GitHub

Your LazyColumn recomposes on every scroll

Siddharth Pandalai — Sun, 30 Aug 2026 06:26:12 +0000

A feed screen felt heavy while scrolling, only on mid-range phones. Layout Inspector told the whole story: every visible row was recomposing on every scroll frame, including rows whose data had not changed at all.

There was a ghost in the recomposition, and it had one cause.

Compose can skip, if you let it

Compose has a quiet superpower called skipping. When a composable's inputs have not changed, Compose skips re-running it entirely. That is most of why it is fast.

Skipping depends on stability. To skip a composable, Compose has to prove its parameters did not change. Some types make that proof easy. Others make it impossible.

A plain List is one of the impossible ones. List is an interface. The thing behind it could be a mutable list that changed under Compose's feet, and the compiler cannot rule that out. So Compose treats every List parameter as unstable, assumes it might have changed, and recomposes the rows that read it. On a scrolling feed, that means redrawing everything you can see, constantly.

The fix is the type

// before: List is unstable, rows cannot skip
@Composable fun Feed(items: List<Post>) { ... }

// after: an immutable list is stable, skipping works
@Composable fun Feed(items: ImmutableList<Post>) { ... }

Use kotlinx.collections.immutable and build the list with persistentListOf(...) or .toImmutableList(). Now Compose knows the collection cannot change, and it skips rows whose data is unchanged.

While you are there, give the items a key:

LazyColumn {
    items(items, key = { it.id }) { post -> PostRow(post) }
}

Without keys, Compose tracks rows by position. Insert one at the top and every row below shifts identity, so more of them redraw than needed. A stable key ties a row to its data.

See it for yourself

Turn on recomposition counts in Layout Inspector and scroll. With an unstable list, the counter on every row climbs. Switch to an immutable list and add keys, and the counters go still. That stillness is the whole point.

The takeaway

Compose is not slow. It is fast by default. Almost every "Compose is janky" story is really the same story: someone handed a composable a type it could not reason about, so it stopped skipping and started repainting the house.

The Recomposer only redraws the room when you give it a reason. Stop giving it reasons.

🌀 Iteration 4 of **The Loopdown. field notes from an engineer who writes.
Series: **Ghosts In The Recomposition* · Featuring: The Recomposer*
📚 The full series: Ghosts In The Recomposition

Follow the loop → LinkedIn · dev.to · GitHub

The 5-second window that crashes your service

Siddharth Pandalai — Fri, 28 Aug 2026 15:00:33 +0000

Our background service crashed for thousands of users, and the stack trace pointed at a line that does nothing wrong.

The exception was ForegroundServiceDidNotStartInTimeException. I had to look it up. And once I understood it, a whole class of "works on my machine" bugs made sense.

The promise you make

When you start a foreground service, you are telling Android something specific: I am about to show a persistent notification and do work the user cares about, so please do not kill me the moment the screen sleeps. That is a real privilege. Foreground services get to keep running when almost nothing else can.

Android grants it on one condition. You have about 5 seconds from starting the service to calling startForeground() with a notification. Keep that promise and you get to stay. Miss it and the system kills the service and throws.

Why it only broke for some users

Our service did this:

override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
    val trip = tripStore.restoreLastTrip()   // disk + db read
    val config = settings.load()             // more io
    startForeground(ID, buildNotification(trip, config))
    return START_STICKY
}

On my phone, restoreLastTrip() and settings.load() finished in under 100 milliseconds. On a cheap device under memory pressure, with the disk busy and the CPU throttled, they sometimes took four or five seconds. By the time we reached startForeground(), the window had closed. The crash only ever showed up on low-end devices, which is exactly the population least likely to file a good bug report.

The fix

Post the notification first. Always. Then do the slow work.

override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
    startForeground(ID, buildMinimalNotification())   // keep the promise instantly

    serviceScope.launch {
        val trip = tripStore.restoreLastTrip()
        val config = settings.load()
        updateNotification(buildNotification(trip, config))   // enrich it later
    }
    return START_STICKY
}

The minimal notification can say something plain like "Starting trip tracking." The user sees it for a fraction of a second before the real one replaces it. That is a fine price for not crashing.

The Android 12 twist

On Android 12 and up there is a second rule that catches people. In many cases you cannot start a foreground service from the background at all. If your trigger fires while the app is not visible, the launch itself throws.

The answer is usually not to fight it. It is to use WorkManager with an expedited request, which is the platform's sanctioned way to say "this is urgent, but let the system schedule it."

val work = OneTimeWorkRequestBuilder<TripWorker>()
    .setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST)
    .build()
WorkManager.getInstance(context).enqueue(work)

The takeaway

The platform is not out to get you. Every one of these rules exists because some app, somewhere, tried to run forever and drained a stranger's battery. Post your notification first, respect the background-start limits, and the system leaves your work alone.

Doze the Jailer runs the night shift. You get 5 seconds to explain why you belong. Explain fast.

🌀 Iteration 3 of **The Loopdown. field notes from an engineer who writes.
Series: **The Night Shift* · Featuring: Doze The Jailer*
📚 The full series: The Night Shift

Follow the loop → LinkedIn · dev.to · GitHub

CancellationException is not an assassin

Siddharth Pandalai — Sun, 02 Aug 2026 07:30:50 +0000

I cancelled a coroutine. It kept running for 8 more seconds. It just did not care.

This was a search screen. You type, it fires a network request. Type again, it cancels the old request and fires a new one. Standard stuff. Except the old request kept running, and every so often it finished last and painted stale results right over the fresh ones. I had called cancel. I had watched it run in the debugger. The job was "cancelled." And still it went on.

The culprit was one line I wrote myself.

Cancellation is a message, not a bullet

This is the part people miss about Kotlin coroutines. Cancelling one does not reach in and kill it. It cannot. The coroutine has to cooperate. So the machinery throws a CancellationException up through your suspend calls, and that exception is the message: we are done, unwind, release your resources, stop.

Your job is to let that message travel. Most cancellation bugs are really one bug: you stopped the message from traveling.

The line that ate the message

try {
    results = api.search(query)   // a suspend call
} catch (e: Exception) {
    log("search failed")
}

This looks careful. It looks like good defensive code. It is a trap.

CancellationException extends Exception. So when cancellation fires mid-request, this catch (e: Exception) grabs it, logs "search failed", and carries on as if a network error happened. The coroutine never unwinds. The framework thinks you handled something. The work continues.

You caught the messenger, logged that he looked upset, and locked him in a cell. The message he was carrying never got delivered.

Four ways to stop doing this

1. Catch what you actually expect. Ninety percent of the time you do not want Exception. You want the specific thing that can go wrong.

try {
    results = api.search(query)
} catch (e: IOException) {
    showOfflineState()
}

CancellationException is not an IOException, so it sails right past and does its job.

2. If you must catch broadly, rethrow cancellation first.

try {
    results = api.search(query)
} catch (e: CancellationException) {
    throw e                       // let the message through
} catch (e: Exception) {
    log("search failed")
}

3. Know that runCatching has the same trap. It is a lovely little helper and it catches CancellationException too.

val result = runCatching { api.search(query) }   // also swallows cancellation

If you use it inside a coroutine, check for cancellation and rethrow, or do not use it there.

4. For cleanup that must run even while cancelling, use NonCancellable. A naked catch is the wrong tool for "always close this".

try {
    stream.write(data)
} finally {
    withContext(NonCancellable) {
        stream.flushAndClose()    // runs even though the coroutine is cancelling
    }
}

Why the language made it this way

Structured concurrency is the reason. When a parent scope cancels, every child needs to wind down cleanly and report back up. That only works if cancellation propagates. If any link in the chain swallows the exception, the parent never learns the child stopped, and your careful tree of coroutines turns into orphans that run in the dark.

So CancellationException is not an error to be defended against. It is the one exception in the system that is doing exactly what you asked. It is the app shutting things down cleanly, on time, on request.

The takeaway

Cancellation is a conversation, not a kill switch. If you swallow the message, the work does not stop. It just stops telling you it is still running.

Do not shoot the messenger.

🌀 Iteration 2 of **The Loopdown. field notes from an engineer who writes.
Series: **The Coroutine Court* · Featuring: The Messenger*
📚 The full series: The Coroutine Court

Follow the loop → LinkedIn · dev.to · GitHub

Teaching a phone to disbelieve its own GPS

Siddharth Pandalai — Sun, 19 Jul 2026 19:25:38 +0000

The bug report came in on a Tuesday. One line:

"Your app says I hit 400 kmph. I was at a red light."

He wasn't lying. Neither was the app. The phone genuinely believed it, and that is the interesting part.

I work on mileage tracking. If you have ever had an app quietly log your drives for expenses or taxes, that is the category. Trip accuracy is not a feature of the product. It is the product. When we started, ours sat around 50 percent, and almost every missing point traced back to the same thing: the phone lying to us with total confidence.

Here is how we got it to 95, and the one idea underneath all of it.

GPS is a witness with a concussion

We treat GPS like a source of truth. Out in the world, where people actually drive, it behaves more like a witness who took a hard knock to the head. Confident. Cooperative. Frequently wrong.

Three places break it badly:

Tunnels. The receiver loses its view of the sky. Instead of admitting that, it keeps reporting the last position it had, sometimes for 30 to 40 seconds. Then you come out the other end, it reacquires, and it snaps to your real location in a single jump. Take that jump, divide by the tiny time it took, and you get a parked car doing 400 kmph.

Urban canyons. Signals bounce off glass towers before reaching you (multipath, if you want the word). The phone averages the reflections and places you a street or two over, very sure of itself.

Parking garages. Nothing, then noise, then nothing again.

None of these are edge cases. They are Tuesday. So the question stopped being "how do we get better GPS" and became "how do we stop believing bad GPS."

Fix 1: catch the liars

The cheapest win first. For any travel mode there is a physically possible envelope. A person walking does not teleport 200 meters in a second. A car does not accelerate like a missile. So before a reading touches the trip, check whether it implies something physics would not allow.

fun GpsFix.isImpossible(prev: GpsFix, mode: Mode): Boolean {
    val meters = haversine(prev, this)
    val seconds = (timestamp - prev.timestamp).coerceAtLeast(1)
    val speed = meters / seconds
    return speed > mode.maxPlausibleSpeed   // walking, cycling, driving each differ
}

If it is impossible, drop it. This one guard killed the most embarrassing errors on its own, including the 400 kmph report. It is not clever. It just refuses to be gaslit.

Fix 2: dead reckoning, so a gap is not a hole

Rejecting bad points leaves you with gaps, and a tunnel is a big one. If you freeze until GPS comes back, the trip gets a straight line cutting across three streets.

So when GPS drops out, stop waiting for it and estimate. Take the last good heading and speed, read the accelerometer, and carry the position forward yourself. Old sailors did this by feel, no stars, no landmarks, just direction and time and a good guess. It drifts, so you cannot lean on it for long. But a tunnel is short, and "roughly right for 40 seconds" beats "confidently wrong" or "a hole in the map."

fun deadReckon(last: Position, imu: Imu, dt: Float): Position {
    val speed = last.speed + imu.forwardAccel * dt
    val distance = speed * dt
    return last.movedBy(distance, heading = last.heading + imu.turnRate * dt)
}

The trick is knowing when to trust it and when to hand control back to GPS the moment GPS is worth trusting again.

Fix 3: fuse, do not just pick

Which brings us to the real fix. Most of the accuracy came from stopping the "believe whoever spoke last" habit and weighing every input by how much it deserves belief right now.

A clean, consistent GPS fix pulls the estimate hard toward itself. A jittery one barely moves it. The dead-reckoned guess fills the space between. Nobody gets a veto. Everybody gets a vote, weighted by confidence.

A Kalman filter is the textbook home for this, and if you reach for one, good. But the win is not the filter. The win is the mindset: hold several noisy opinions at once, and lean toward the one that looks trustworthy this second.

The unglamorous half

None of this matters if the tracker is dead. On Android, the moment the screen sleeps, the system starts looking for background work to kill, and aggressive OEM skins kill harder. We ran the pipeline in a foreground service with a small floating bubble, partly so the user could see it working, mostly so the OS would leave it alone. A tracker that gets killed is 0 percent accurate no matter how good the math is. I spent nearly as long on staying alive as on the algorithm.

What actually took us from 50 to 95

Not one silver bullet. Spike detection removed the garbage. Dead reckoning covered the gaps. Fusion made the whole thing coherent. Staying alive made it real. Each one bought a chunk, and they compounded.

Steal this

Treat every external input as a witness who might be concussed, not a source of truth.
Give physics a veto. The cheapest correctness check is "could this even happen."
When a signal drops, degrade to a rough estimate instead of freezing or guessing wildly.
Weight inputs by live confidence, not recency.
Keep the thing alive first. Perfect logic in a killed process is worth nothing.

The one line I kept after all of it: good systems are not the ones with perfect inputs, because nobody gets perfect inputs. Good systems assume their inputs will lie, and plan for the day they do.

Trust, but verify. Especially your own sensors.

🌀 Iteration 1 of **The Loopdown. field notes from an engineer who writes.
Series: **Sensors Who Lie* · Featuring: The Concussed Witness*
📚 The full series: Sensors Who Lie

Follow the loop → LinkedIn · dev.to · GitHub