DEV Community: Siddharth Pandalai

Every filter needs a documented exception

Siddharth Pandalai — Wed, 23 Sep 2026 04:01:24 +0000

A filter with no exceptions has not met production yet. It has only met your test data.

The rule that was right nearly always

GPS reports an accuracy radius with every reading. Ours had a straightforward rule: anything worse than 50 metres is persisted, but does not count toward trusted distance.

val accuracyGated = fix.accuracyM > MAX_ACCURACY_THRESHOLD_M   // 50.0

This is sound. A 200 metre radius means the phone is in a basement, an underground car park, or surrounded by reflective towers. Counting that as travelled distance produces nonsense.

Then we hit the legitimate case: a vehicle parked for a long stop. Genuinely stationary. Decent fix. But occasionally reporting a slightly wider radius, and under the blanket rule those readings stopped contributing. The stop appeared as a hole in the journey.

Two bad fixes and one good one

Loosen the threshold. Move 50 to 70 and the complaint disappears, along with the protection you added the rule for. This is not solving the edge case, it is deleting the rule.

Special-case it silently. Add || fix.speedMps < 0.1 somewhere in the condition, move on. It works today and becomes archaeology within a quarter.

Name the exception. What we actually did:

// Stationary after recent movement with still-reasonable accuracy: the device is
// reliably placed, not drifting, so it may contribute despite the accuracy gate.
val exceptionalStationary =
    fix.speedMps <= EXCEPTIONAL_STATIONARY_SPEED_MPS &&   // 0.1 m/s: genuinely not moving
        fix.accuracyM < EXCEPTIONAL_STATIONARY_ACCURACY_M && // 20m: still a good fix
        hasMovementHistory()                                  // and it was moving recently

val accuracyGated = fix.accuracyM > maxAccuracyThreshold && !exceptionalStationary

Three conditions, all required, describing exactly one situation. The rule stays strict for everyone else.

Why the name is the important part

The logic here is four lines. Any competent engineer would arrive at something similar. What makes it survive is that it is called exceptionalStationary and carries a comment explaining the reasoning.

An unnamed condition is indistinguishable from a bug, and it gets treated like one. Somebody tidying up in six months sees speedMps <= 0.1f && accuracyM < 20f && hasMovementHistory() inline in a boolean, cannot work out why anyone would want that, and removes it. Tests pass, because nobody wrote a test for a case nobody could explain. The regression surfaces in support tickets a month later.

A named exception with a comment and a test is a different object entirely. It says: this is deliberate, here is the situation, here is why the general rule is wrong for it.

The other exception in the same pipeline

There is a second one worth showing, because it demonstrates the discipline that keeps exceptions from metastasising. After a pause and resume, the user may genuinely have moved while tracking was off, so the teleport-spike gate is relaxed for a grace window.

But the accuracy gate stays fully enforced during that window.

Relaxing one rule must never silently relax the neighbours. An exception should be as narrow as the situation that justifies it, and no narrower than the code makes explicit.

The takeaway

Write the rule. Then go looking for the legitimate case it breaks, because there is always one. When you find it, do not weaken the rule and do not smuggle in a condition. Give it a name, a comment with your reasoning, and a test.

Undocumented special cases do not survive contact with a refactor. Documented ones do.

🌀 Iteration 12 of **The Loopdown. field notes from an engineer who writes.
Series: **Sensors Who Lie* · Featuring: The Concussed Witness*
← Previously in this series: When two sensors disagree, rank them
📚 The full series: Sensors Who Lie

Follow the loop → LinkedIn · dev.to · GitHub

Never silently change a number someone gets paid on

Siddharth Pandalai — Sun, 20 Sep 2026 04:01:23 +0000

Our algorithm decided a driver had travelled 4km less than they thought. It was probably right. Shipping that silently would still have been wrong.

When cleaning stops being technical

Mileage tracking ends in an expense claim. Someone drives, the app measures, and the measurement becomes money.

Our pipeline removes several categories of distance: readings from mock location apps, physically implausible jumps, and teleport spikes over five kilometres in a single step. The resulting number is more accurate than the raw sum. That is not in dispute.

The mistake is thinking accuracy is the whole job.

A driver who believes they did 40km and sees 36km cannot distinguish between a careful algorithm and an employer quietly trimming expenses. From where they sit, both look identical: a smaller number, no explanation. Being right is invisible.

Explicit degradation, in the UI

The fix is not better filtering. It is showing the work.

Show the original next to the cleaned figure. Both numbers exist in the data model, so both can appear. The user sees that we measured 40km and are proposing 36km, rather than discovering 36km as if it were the only thing that ever happened.

Name what was removed. Not "adjusted for accuracy" but the actual categories: abnormal distance, mock distance, spike distance. Categories are checkable. Vagueness is not.

Let them overrule it. The trip screen has a toggle for whether the abnormal segment is subtracted:

var final = smartAnalysis.originalDistance
if (removeAbnormal) final -= smartAnalysis.abnormalDistance

This one gets pushback in review. Why let a user override the algorithm? Two reasons. They were physically present and we were not, so on a genuinely ambiguous journey they hold information the pipeline does not. And if our threshold is wrong, this is the cheapest possible feedback channel. The alternative is not that they accept it. The alternative is that they escalate to their finance team, who escalate to us, three weeks later, with no data attached.

Do not cry wolf. In the irregularities view, an app-killed event is explicitly classified as not an irregularity, because the tracker recovers on its own. If every notice is alarming, users learn to dismiss all of them, and the disclosure you worked on becomes noise.

This needs the data model to cooperate

None of this is possible if the pipeline throws away what it rejects. Showing original versus cleaned requires both numbers to survive. Naming the categories requires per-category accumulators. Letting the user toggle removal requires the removed distance to still be sitting there, addable back.

Transparency is a data-modelling decision made months before it becomes a UI decision.

The general case

The pattern applies well beyond mileage. Fraud scores that block a transaction. Ranking systems that decide what a seller earns. Time trackers. Usage-based billing. Anything where a system's output becomes an input to somebody's money, time, or reputation.

For those systems, correctness is table stakes. The actual product is: show the original, show the delta, show the reason, and let them push back.

Being right in silence is just asking to be trusted. Showing the working is how you earn it.

🌀 Iteration 11 of **The Loopdown. field notes from an engineer who writes.
Series: **Chain Of Custody* · Featuring: The Archivist*
← Previously in this series: Your data model is where uncertainty goes to die
📚 The full series: Chain Of Custody

Follow the loop → LinkedIn · dev.to · GitHub

When two sensors disagree, rank them

Siddharth Pandalai — Fri, 18 Sep 2026 06:44:33 +0000

GPS said the car was moving. The accelerometer said the phone had not twitched in ten minutes.

Asking a sensor to check itself

Stationary drift is the oldest problem in location tracking. A parked phone reports small movements in every direction. Sum the gaps and a car that never left the car park has quietly driven three kilometres.

The obvious defence is to look at reported speed and ignore readings that claim you are not moving. It half works, because the drift sometimes carries a plausible speed with it. The fix looks internally consistent while being completely wrong.

That is the structural problem. A single sensor can only be validated against itself, so every threshold you add is really a guess about your own input. You can spend months making that guess more elaborate without making it more correct.

A second signal that fails differently

The accelerometer is a poor navigator. Integrate it for position and the error compounds within seconds. But ask it a narrower question, "did this device physically move", and it is far better than GPS, because its failure modes have nothing to do with satellites, tunnels, or reflections off a glass tower.

Two sensors that fail differently can check each other. So the pipeline takes both:

fun process(
    fix: GpsFix,
    motionStill: Boolean = false,   // IMU says physically still
    harshAccel: Boolean = false,    // hard accel or braking this fix
): ProcessResult?

and when they disagree about movement, the IMU wins:

// drop the sub-gate wander when GPS history shows no movement,
// OR the IMU says still, OR this coincides with a harsh accel/brake event
if ((displacement < gate || stationaryMicroJitter) &&
    (!hasMovementHistory() || motionStill || harshAccel)) {
    return null
}

The comment in our source is blunt about why: accelerometer stillness is authoritative.

Harsh braking gets the same authority for a subtle reason. A hard stop can momentarily look like stillness to a speed gate, and the jitter it produces should not be counted as travelled distance either.

Rank per question, not overall

The important nuance is that we did not decide the accelerometer is "better". It is useless for position. GPS remains the only thing that knows where you are.

What we ranked was authority on one specific question:

Question	Authority
Where are we?	GPS
Did we move at all?	Accelerometer
How fast, over a distance?	GPS, checked against implied speed
Is the environment trustworthy?	Neither, the quality score

A sensor is not good or bad. It is good at some questions and bad at others, and a fusion strategy is mostly a table like that one made explicit.

The cheap version of the same idea

You do not need an IMU to use this principle. At journey level we compare total GPS distance against the vehicle odometer reading:

val discrepancyRatio = abs(odometer - total) / odometer
if (discrepancyRatio > 0.3) warn(LargeDiscrepancy("odometer-vs-gps", discrepancyRatio))

Two completely independent measurements of one number. When they disagree by more than 30 percent, something is wrong and a human should look, rather than the system silently trusting whichever number it happened to compute.

Most systems have a signal like this lying around unused. A client-side event count against a server-side one. A cache's view of a value against the source of truth. A model's confidence against observed outcomes.

The takeaway

Do not build a smarter threshold on a lonely sensor. Find a second signal that fails differently, and give it authority over the specific question it is genuinely good at.

Correlation beats cleverness.

🌀 Iteration 10 of **The Loopdown. field notes from an engineer who writes.
Series: **Sensors Who Lie* · Featuring: The Concussed Witness, The Second Witness*
← Previously in this series: One global threshold is how you delete valid data
📚 The full series: Sensors Who Lie

Follow the loop → LinkedIn · dev.to · GitHub

Your data model is where uncertainty goes to die

Siddharth Pandalai — Wed, 16 Sep 2026 05:08:31 +0000

The sensor knew how much to trust itself. Our database column did not have room for that, so we threw it away on the way in.

Everything arrives with an error bar

Android hands you a Location object that is far richer than a point on a map. It has an accuracy radius in metres, the provider that produced it, a bearing, an altitude, a timestamp, sometimes a speed. The platform is telling you, on every reading, how much to believe it.

This is not special to GPS. Models return confidences. Caches know their staleness. Upstream APIs know whether they served fresh data or a fallback. Almost every value in a real system arrives with a companion signal about its own reliability.

And almost every schema drops it.

Our first table was the obvious one:

@Entity
data class LocationData(
    val lat: Double,
    val lng: Double,
    val speed: Float,
    val date: Long,
)

Reasonable. Minimal. Exactly what the feature needed. It also silently discarded the accuracy radius on every write, which meant the discard was permanent.

The questions you cannot answer later

Within a few months, the real questions arrived:

Was this journey tracked well, or was the phone in a basement the whole time?
Which readings were fused location and which were raw GPS?
Was the device physically moving when this arrived, or just drifting?
Why is this trip's distance different from the driver's odometer?

Not one of those is an algorithm problem. They are all schema problems. The information existed at write time, in memory, for free, and we did not have a column for it.

You cannot backfill confidence. Once the row is written without it, that uncertainty is gone for every future reader, forever.

The row that carries its papers

What we persist now:

data class LocationData(
    // the reading
    val lat: Double, val lng: Double, val speed: Float,
    val bearing: Float, val altitude: Double, val locationTime: Long,
    // how much to trust it, and where it came from
    val accuracy: Float,
    val provider: String,
    // what the device was doing
    val gyroscopeX: Float, val gyroscopeY: Float, val gyroscopeZ: Float,
    val accelerometerX: Float, val accelerometerY: Float, val accelerometerZ: Float,
    val batteryPercentage: Double,
    val deviceModel: String, val appVersionName: String,
    // what we already decided about it
    val isMock: Boolean,
    val isAbnormal: Boolean,
    val isPaused: Boolean,
    val displacement: Double,
)

Three groups, and the third is the one people skip. Storing our own verdict next to the evidence means a later reader can see both what we concluded and what we concluded it from. When a threshold turns out to be wrong, every affected row is identifiable rather than theoretical.

Confidence as a number, not a vibe

Raw columns let you reconstruct the truth. They do not make it usable in a UI. So the environment collapses into a single score, 0 to 100:

Condition	Penalty
Permission missing	30
Mock location	25
Process killed	20
Restarted	20
GPS off	20
Battery optimised	15
Power saver	15

plus an accuracy tier (15m or better is free, worse than 75m costs 20) and a small bonus when the fix stream is stable. Now the app can say "this journey was tracked in poor conditions" instead of presenting a number with false confidence.

The rule

Design the row to carry doubt. If a value can be wrong, the schema needs somewhere to record how wrong, where it came from, and what you already decided about it.

Those columns are cheap. Add them before you need them, because the alternative is discovering at query time that the answer was thrown away at write time, months ago, by a schema that assumed confidence did not matter.

🌀 Iteration 9 of **The Loopdown. field notes from an engineer who writes.
Series: **Chain Of Custody* · Featuring: The Archivist*
📚 The full series: Chain Of Custody

Follow the loop → LinkedIn · dev.to · GitHub

One global threshold is how you delete valid data

Siddharth Pandalai — Mon, 14 Sep 2026 04:01:20 +0000

Our GPS filter worked perfectly, right up until someone sat in Bangalore traffic.

The phantom distance problem

A parked phone does not sit still in the data. The reported position wanders a few metres in every direction, and if you naively sum the gaps between readings, a stationary car quietly accumulates kilometres. On a mileage app that becomes an expense claim, so it matters.

The fix looks trivial. Ignore any step below some minimum:

if (displacement < MIN_DISPLACEMENT_M) return   // 5.0, felt about right

Parked cars stop drifting. Tests pass. Ship.

Then a driver crawls through traffic at walking pace for forty minutes. Every genuine step they take is under five metres. We deleted the whole journey and told them they had not moved.

The constant was making a claim

MIN_DISPLACEMENT_M = 5.0 looks like a number. It is really an assertion: five metres means the same thing whether you are parked, walking, cycling, on a motorway, or crawling in first gear. That assertion is false, and the filter had no way to know it.

Every threshold worth keeping is a function of context. Ours ended up depending on three things.

1. Speed bands

private fun minDisplacementForSpeed(speedMps: Double): Double = when {
    speedMps < 2.5 -> 2.0    // walking
    speedMps < 7.0 -> 3.0    // cycling
    else           -> 5.0    // driving
}

Faster travel expects and tolerates bigger steps between readings. Slower travel needs a tighter gate or you erase it.

2. Time-gap tiers

An implausible speed is only implausible relative to how long you were not looking. Under normal sampling, a 5km jump is a teleport. After a six hour gap it is a commute.

private fun isAbnormal(displacement: Double, impliedSpeed: Double, dtSec: Long) = when {
    dtSec < 30      -> displacement > 5_000 || impliedSpeed > 70.0  // ~252 km/h
    dtSec <= 300    -> impliedSpeed > 150.0
    dtSec <= 3_600  -> impliedSpeed > 100.0
    dtSec <= 21_600 -> impliedSpeed > 60.0
    else            -> displacement > 10_000   // stop testing speed entirely
}

Tunnels, killed processes, flights and genuine glitches all produce a jump. The gap is what tells them apart, so the gap has to be an input.

3. Recent history

This is the one that actually rescued the traffic case. A small step is only treated as jitter when the recent window agrees that nothing is happening:

private fun hasMovementHistory(): Boolean =
    recentSpeedHistory.isNotEmpty() && recentSpeedHistory.average() >= 1.5   // last 5 fixes

Sustained slow movement is movement. Genuine stillness is stillness. A rolling window can tell them apart. A constant never could.

Make them configurable while you are at it

Once thresholds are context-dependent there are more of them, and you will get some wrong. Ours live in one serialisable object rather than scattered const vals:

@Serializable
data class AbnormalDetectionConfig(
    val walkingMaxMps: Double = 2.5,
    val walkingJitterM: Double = 2.0,
    val cyclingJitterM: Double = 3.0,
    val drivingJitterM: Double = 5.0,
    val speedHistorySize: Int = 5,
    val movementHistoryMps: Double = 1.5,
    val spikeHardGateM: Double = 5_000.0,
    // ...gap tiers
)

Tuning becomes a config change rather than a release. The defaults reproduce the old hardcoded values exactly, so extracting them proved nothing changed.

The takeaway

When you write a constant into a filter, ask what context you are assuming. If the answer is "all of them", you have not written a threshold. You have written a bug with a delay on it.

🌀 Iteration 8 of **The Loopdown. field notes from an engineer who writes.
Series: **Sensors Who Lie* · Featuring: The Concussed Witness*
← Previously in this series: Filtered should never mean deleted
📚 The full series: Sensors Who Lie

Follow the loop → LinkedIn · dev.to · GitHub

Filtered should never mean deleted

Siddharth Pandalai — Sun, 06 Sep 2026 06:33:33 +0000

We shipped a filter that threw away bad GPS readings. Months later somebody asked whether it was working, and I could not answer. The evidence was gone.

That question changed how I build anything that rejects data.

The obvious version, and why it rots

Mileage tracking depends on trustworthy distance, and GPS lies constantly. So the first version of our cleanup did what everyone's first version does:

if (!fix.isPlausible(previous)) return   // drop it, move on
accumulateDistance(fix)

Clean data comes out the other end. It feels responsible. It is also a trap, because that return destroys the only record that could ever tell you whether the rejection was correct.

Six months in, someone asked the reasonable question: is the filter right? I could not say how many readings we had dropped, on which journeys, or whether any of them had been a genuine drive through a tunnel rather than a glitch. We had built a thing that made a judgement call thousands of times a day and kept no record of any of it.

Persist, then classify

The rebuild flipped the default. Rejection stopped being a return and became a label.

Only two cases are still deleted, because they cannot physically be real:

// impossible coordinates
if (fix.lat !in -90.0..90.0 || fix.lng !in -180.0..180.0) return null
// impossible accuracy: too precise to be true, or useless
if (fix.accuracyM <= 0.1f || fix.accuracyM >= 250f) return null

That is the entire delete list. Everything else is persisted and sorted into named accumulators:

originalDistanceM += displacement          // every metre we ever saw
when {
    fix.isMock  -> mockDistanceM += displacement
    abnormal    -> {
        abnormalDistanceM += displacement
        if (isHardSpike) spikeDistanceM += displacement
    }
    accuracyGated -> { /* recorded, deliberately not counted */ }
    else -> cleanedDistanceM += displacement
}

Five numbers instead of one. The UI shows cleaned. The rest live beside it.

And the row itself keeps its provenance: accuracy, provider, bearing, altitude, the gyroscope and accelerometer snapshot, battery level, device model, plus isMock and isAbnormal. A filtered reading is still sitting there, labelled with exactly why it did not count.

What that bought

Disputes became answerable. This is mileage that turns into an expense claim. When a driver says the distance is wrong, we pull the journey and show what was removed and why. Before, the honest answer was "the algorithm decided", which is not an answer.

Thresholds became tunable. We could replay real journeys and ask how much distance we were classifying as abnormal. Twice the data said our threshold was too aggressive on genuine motorway driving, and we moved it. That correction is impossible if the rejected steps are gone.

Ratios became alarms. Because we keep both numbers, we can assert on their relationship:

cleaned = total - (mock + abnormal)

and warn when abnormal exceeds half a journey, or when GPS distance and the vehicle odometer diverge by more than 30 percent. If most of a real trip is landing in the abnormal bucket, the threshold is wrong, not the driver.

The general rule

This is not a GPS lesson. Any system that rejects data has the same shape: fraud scoring, metrics pipelines, log sampling, feature stores, anything with a validation step. The moment you drop a record, you have made an irreversible claim about it and destroyed the ability to check.

Keeping it is usually cheap. A boolean column and a second accumulator is nothing next to permanently losing the answer to "is this working?"

So: filtered should never mean deleted. Filtered means "not counted, and here is the reason, written down, next to the thing itself."

If your pipeline drops rows, find out where they go. "Nowhere" is an answer, just not a good one.

🌀 Iteration 7 of **The Loopdown. field notes from an engineer who writes.
Series: **Sensors Who Lie* · Featuring: The Concussed Witness*
← Previously in this series: Teaching a phone to disbelieve its own GPS
📚 The full series: Sensors Who Lie

Follow the loop → LinkedIn · dev.to · GitHub

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