DEV Community: Kordelis

Two screens need the same warning. Where should the state live?

Samya — Thu, 12 Nov 2026 06:39:03 +0000

Imagine an Android app with two screens: an order history screen and an account screen. Both need to warn the user when an earlier order needs attention. From either screen, the user can open a dialog, dismiss it or start a recovery action.

The first version might put the logic in the order history ViewModel. Then the account screen needs it too.

Sharing the recovery use case helps. Both ViewModels can call the same function. But each screen may still need to decide when to show the warning, hold the dialog state and handle the user’s actions. That’s where the duplication starts to feel less trivial.

One option is to extract that behaviour into a small presentation component that each ViewModel uses:

interface OrderWarning {
    val state: StateFlow<OrderWarningState>

    fun check()
    fun dismiss()
    fun recover()
}

The component could use the shared domain logic while also managing the state needed to show the warning. Each screen can then decide how to expose that state to its UI.

I like this approach when the behaviour is the same in both places. The ViewModels no longer need to repeat every detail of checking, dismissing and recovering. It also gives the warning behaviour a smaller surface to test.

But extracting it doesn’t answer every question.

What does “dismiss” mean?

Suppose the user dismisses the warning on the order history screen and then opens the account screen.

Should it appear again?

If each screen has its own warning component, each can hold its own dismissal state. If both screens use the same instance, dismissal can affect both. Either could be right, depending on the experience the app is trying to provide.

I would separate that decision from the order’s actual status. Dismissing a dialog shouldn’t quietly mark the underlying order as recovered. One is a presentation choice; the other changes what the app knows about the order.

There is a similar question around recovery. If both screens can start it, the shared domain or data layer needs an appropriate way to handle repeated or overlapping requests. A shared UI component alone doesn’t guarantee that the operation runs only once.

What about a single screen state?

A ViewModel may already expose a StateFlow<ScreenState>. Adding a separate OrderWarning.state gives the UI another state source to observe.

That isn’t automatically a problem. A small, self-contained warning can be easier to understand on its own. But if the screen already has a clear convention of exposing one state, combining the warning into that state may make the screen easier to follow.

For example, the screen state could contain an OrderWarningState, while screen events are forwarded to the warning component. There will still be some wiring in each ViewModel, but it can be a reasonable amount of repetition if it keeps the screen’s public interface clear.

The other direction is to share a ViewModel at a level above both screens. That can make sense if the warning truly belongs to that shared part of the navigation flow. I’d be more cautious if the only reason for sharing the ViewModel is to avoid a few repeated lines: its scope and lifetime then become part of the decision too.

What I’d look at first

Before choosing a pattern, I’d write down the expected behaviour for a few cases:

Dismiss the warning on one screen, then open the other.
Start recovery and leave the screen before it finishes.
Trigger recovery twice.
Reopen the app while the order still needs attention.

Those cases help distinguish the state that belongs to the screen from the order status that should be shared. They also make a useful starting point for tests.

I wouldn’t extract a component just because two ViewModels call the same use case. But when they repeat the same presentation behaviour around that call, a small reusable component can be worth trying. I’d keep it if it makes the screens and their tests easier to understand—and reconsider it if following the behaviour means chasing through several layers.

The upload started. Can the user leave the screen?

Samya — Mon, 09 Nov 2026 04:59:47 +0000

A user picks a photo, taps Upload, and sees a progress bar.

Then they switch to another app.

When they come back, the upload is still sitting there. Did it stop? Is it waiting for a connection? Did the server receive the photo?

The progress bar doesn’t tell them.

I think this is an easy part of an upload flow to miss. We tend to test the happy path with the screen open: select a file, start the upload, watch it finish. But people don’t always wait patiently on that screen.

Before choosing an Android API, I’d start with a simpler question: what should the person be able to do while the upload is happening?

Should the upload wait, or should it start now?

Not every upload needs the same treatment.

A small transfer that can wait for a connection has different needs from a large file the user just selected and expects to finish soon.

For work that can be scheduled and retried, WorkManager is often a reasonable place to start. You can set conditions, such as network availability, and observe the work’s state when the user returns.

For a longer transfer started by the user, where progress needs to stay visible and interruption would be disruptive, Android also has user-initiated data transfer jobs. They’re available from Android 14 and have their own scheduling and notification requirements.

I wouldn’t switch every upload to a new API just because it’s available. Android’s guidance says to keep using WorkManager for short, interruptible transfers where it already fits. The useful choice depends on the transfer and the experience you want to provide.

Android’s guide to data-transfer options walks through the trade-offs.

What if the phone never receives the answer?

This case is less obvious.

Imagine the server receives the photo successfully, but the connection drops before the response reaches the phone.

The server has the file. The app thinks the attempt failed.

If the app retries, does it create another copy?

That isn’t something the background-work API can decide for you. The client and server need a way to recognise that both attempts belong to the same upload. For example, the app could use a stable upload identifier, with the server treating repeated attempts for that identifier as the same operation. Larger transfers may need a resumable protocol that tracks which parts arrived.

The right approach depends on the backend. But I’d want an answer to that question before calling retries “safe.”

When the user comes back

The upload doesn’t have to finish immediately. It does need to be understandable.

When someone returns to the app, they should be able to tell whether the file is waiting for a connection, still uploading, completed, or needs another attempt.

That means the screen can’t rely only on a local isUploading flag that disappears when the screen goes away. It needs to read the relevant work and upload state again.

I’d also keep cancelled separate from failed. If I cancel an upload, “Something went wrong” is a confusing response. I asked it to stop.

A few tests I’d run

Start an upload that takes long enough to interrupt, then try these separately:

Leave the upload screen and return.
Switch to another app and come back.
Turn off the network during the transfer, then reconnect.
Reopen the app while the upload is pending or after it finishes.
Interrupt the connection near completion and check whether retrying creates a duplicate on the server.
Cancel the upload and inspect what remains on the phone and server.

I’d record the device and Android version alongside the results. Leaving a screen, having the system stop the app process, force-stopping the app, and cancelling the work are different situations. Passing one check doesn’t prove the others.

WorkManager can stop a worker for several reasons, including changed constraints, cancellation, or a system request. Android recommends that long operations cooperate with stopping and release resources appropriately. Managing work

A progress bar tells the user that something started. What they see when they come back tells them whether they can trust it.

Watch: When an Android Upload Stops After You Leave the Screen

Location permission denied: what your Android app does next is the real design

Samya — Thu, 05 Nov 2026 06:11:02 +0000

Someone opens a café app and taps "Find cafés near me." Android asks for location access. They choose "Don't allow."

Now what?

Sometimes the answer is: nothing. A dead-end screen, a "location is required" message, maybe a button that fires the same dialog again. I think that is a poor experience when the app could offer another way forward.

The person said no to one way of answering "where should I search?" They didn't say no to the café. They may well know exactly which city they want. If the app can search by city, it already has a second way to help, and all it has to do is say so.

A quick note on the sample before we go on. The permission dialog and app screens in the video are captures from an Android emulator. The character and surroundings are illustrated, and the café names and results are fictional.

Start with the task, not the permission

Location is one way to find a place to search. It isn't the only way, and sometimes it isn't even the best one. Someone planning tomorrow's trip will probably type a city whether or not you have their GPS.

The sample shows two outcomes after the same denial. In the first, the app stops at a message saying location is required. In the second, it explains that location access wasn't granted and offers a city field. Type a city, tap Search, and you land on a screen with fixed illustrative results, not results from a real search service.

Same denial, completely different experience. One of them treats "no" as the end of the conversation. The other treats it as new information.

To be fair, this won't work for every feature. A navigation app can't produce a live position without a real location source, and pretending otherwise would be worse than the dead end. A café directory is different: it can search a place the person gives it. So pick your fallback based on the task, and be upfront when the results will be less precise or less convenient than the location-based version.

Ask less often than you think you need to

Before you build a permission flow, ask whether the task needs device location at all. If the need is occasional, Android's own permission-minimization guidance suggests letting people enter an address or postal code manually. It also covers other approaches depending on how often and how precisely you need location.

If the person does choose "Find cafés near me" and you genuinely need the device's position, ask in context, at that moment, not on first launch. And don't request precise location when approximate will do. Approximate location may be enough for a café search, depending on the feature and the accuracy it needs. What the system shows will vary with the Android version, the permissions you request and what the person chose before, so don't hard-code assumptions about the dialog.

Treat denial as a state you designed

A denied permission should land on a screen somebody thought about, not on whatever the error path happened to produce. For this example, that means four things.

Say what changed, in plain words. "Location access wasn't granted. Search by city instead" tells the person why the nearby search can't run and what to do next. No blame, no jargon.
Make the alternative actually work. A city field that returns nothing useful is worse than no field. Handle empty input, no results and network errors too, because those are the first things a real person will hit.
Leave everything else alone. Someone who denied location can still browse their saved places. If a feature doesn't need location, don't punish it for the permission.
Don't nag. Re-showing the same request right after a "no" is how you teach people to distrust your app. If they later want a location-dependent feature, give them a clear, deliberate way to turn it on.

None of this is exotic. Android's guidance says the same thing: request permission in context, check it every time an operation needs it, and degrade gracefully when access is denied or revoked. See Request runtime permissions.

Test the whole path, not just the dialog

Seeing the permission dialog appear proves very little. What matters is whether a person can understand what happened and still finish what they came to do.

On the Android versions you support, try these:

Deny the request. Is the change explained? Can the person reach the alternative without hunting?
Use the alternative end to end. Enter a city, submit it, follow the results to the next meaningful action. Then break it: empty input, no matches, a failed request.
Grant, then revoke in system settings. Come back to the app and trigger the location action again. Does it re-check access and recover, or crash?
Grant approximate, not precise. Does the feature work with the accuracy it got, or at least explain its limit?
Walk away from the location flow. Can the rest of the app still be used?
Restart the app. Does what's on screen match the current permission and what the person chose?

What we did and didn't verify

The sample is deliberately small. On an Android 16 / API 36 emulator, we captured a real approximate-location prompt, denied it, entered a city and reached the alternative results screen. The results are fixed examples, not output from a search service. We didn't verify the flow on a physical device, and we didn't test every Android version. A production app needs its own search implementation and its own tests for the devices and permission states it supports.

So take the sample as a demonstration of the shape, not as proof it works everywhere.

The question that matters

After someone says no, what can they still do?

In this example, a city field gives them a way forward that the nearby search alone never would. That's a small amount of work for the difference between an app that works with the person's decision and one that argues with it.

Disclosure: This article was drafted with AI assistance.

When larger text puts a button out of reach on Android

Samya — Mon, 02 Nov 2026 16:48:08 +0000

Someone opens a library app to collect a book. They make the text on their phone larger, read the collection details and try to confirm. The label is cut off. On a compact screen, the confirmation button has disappeared below the visible area—and an upward swipe doesn't bring it back.

This is an illustrative example, built to make a layout problem visible. The app screens in our video are real captures from a small Jetpack Compose sample; the surrounding scenes are illustrated. The sample deliberately constrains the layout. It is not a customer app or a claim that larger text breaks every app.

The short video shows the problem and the corrected flow:

The text grew. The layout didn't make room.

In the broken version, we used a custom action with a fixed height and clipped its contents. At a larger font size, the text needed more vertical space than the action allowed. The content area also did not scroll, so the action could move below the viewport with no way to reach it.

Those are two separate problems. A label can be clipped even when its button is on screen. A perfectly readable button can still be unreachable when the page cannot scroll.

Here's the shape of the constrained custom action in the sample, simplified to focus on the constraint:

Box(
    modifier = Modifier
        .fillMaxWidth()
        .height(30.dp)
        .clipToBounds()
) {
    Text(
        text = "Confirm collection",
        fontSize = 20.sp,
        modifier = Modifier
            .padding(start = 16.dp, top = 6.dp)
            .wrapContentHeight(unbounded = true, align = Alignment.Top)
    )
}

This is deliberately restrictive custom UI, not standard Material Button behavior. A fixed height alone does not prove that every button will clip: padding, font metrics, constraints, width and text all affect the result.

Give the content room and a way to scroll

In the corrected sample, the content sits in a vertically scrollable container. The action has a minimum height instead of the broken fixed height, with content-driven padding. Its text can wrap as needed.

The relevant shape looks like this:

Column(
    modifier = Modifier
        .fillMaxSize()
        .verticalScroll(rememberScrollState())
        .padding(24.dp)
) {
    // Book and collection details

    Box(
        modifier = Modifier
            .fillMaxWidth()
            .heightIn(min = 56.dp)
            .clickable { /* confirm the collection */ }
            .padding(16.dp),
        contentAlignment = Alignment.Center
    ) {
        Text("Confirm collection", fontSize = 20.sp)
    }
}

This is a simplified illustration of the layout choices, not a drop-in replacement for every screen. A production action should also have appropriate semantics, a clear role and accessible interaction behavior; a Material button may be a better starting point than a custom clickable Box. Check the surrounding constraints too: changing only the button's minimum height will not fix a parent that clips its children or prevents scrolling. Compose's scroll modifier guidance explains how to make content larger than its available space scrollable.

What we actually tested

We tested the sample on an Android 16 / API 36 emulator in portrait, using a compact configuration of approximately 309 × 686 dp. With the system font scale at 2.0, the broken, non-scrolling layout left the action outside the visible content area. An upward swipe did not change the content. In the corrected version, we scrolled to the action, tapped it and observed the “Reserved” state.

At a 1.6 font scale, the broken custom action also clipped part of its label. The clipping in the capture is subtle: roughly 13% of the glyph height compared with an uncut reference.

This is one emulator configuration, not an accessibility certification or proof of behavior on every device. In an earlier, taller configuration, the action remained reachable. Screen size, density, language, content and font settings can all change the result.

Test the task, not just the first screen

Android 14 introduced non-linear font scaling up to 200%. Larger text sizes do not necessarily scale at the same rate as smaller ones. Android recommends using sp for text and testing at the maximum setting; see Android's font-scaling guidance.

For a practical check:

Set the system font size to its maximum on a test device or emulator. Also try a smaller screen or split-screen window where appropriate.
Open a real flow in your app and complete it. Can you read each label, scroll to the next step and reach the action?
Check long or translated text, error messages and dynamic content. Look for clipping, overlaps and actions hidden by fixed regions.
Repeat at your usual text size too. A change that helps at one size should not make the ordinary flow harder to use.

The aim isn't to make every screen look identical at every setting. It's to make sure the person using the app can still understand it and finish what they came to do.

Disclosure: This article was drafted with AI assistance.

Why did my birthday move? A date-only bug across time zones

Samya — Fri, 30 Oct 2026 03:48:11 +0000

Someone enters their birthday as 12 June. After travelling, they open the app and see 11 June.

They haven't changed it. One possible cause is that the app turned a calendar date into a moment in time, then displayed that moment in a different time zone.

Here's a small example of how that can happen, and what to test in an app that stores birthdays.

Watch the short video: Why did my birthday move?

From 12 June to 11 June

Suppose a birthday is 1994-06-12. An app saves it as midnight UTC:

1994-06-12T00:00:00Z

That timestamp identifies a moment. At that moment in Los Angeles, the local date and time are 11 June 1994, 17:00. If the app converts the timestamp to the device's time zone and takes the date, it will show 11 June.

The time-zone conversion is doing what it was asked to do. The problem is that a birthday was represented as a moment in the first place. Travelling doesn't change a correctly stored birthday.

Here's the conversion in Kotlin:

import java.time.Instant
import java.time.ZoneId

val savedMoment = Instant.parse("1994-06-12T00:00:00Z")
val displayedDate = savedMoment
    .atZone(ZoneId.of("America/Los_Angeles"))
    .toLocalDate()

println(displayedDate) // 1994-06-11

The offset depends on the zone's rules for the date in question. Using a named zone such as America/Los_Angeles lets the time API apply those rules, including daylight saving time.

Keep a birthday as a date

For a birthday, the value we need is a year, month and day. In Java or Kotlin, LocalDate represents that without a time or time zone:

import java.time.LocalDate

val birthday = LocalDate.parse("1994-06-12")
val apiValue = birthday.toString() // "1994-06-12"
val loadedBirthday = LocalDate.parse(apiValue)

check(loadedBirthday == birthday)

The important part is what happens between those two operations. Agree on a date-only value in the API, for example:

{ "birthday": "1994-06-12" }

Then preserve it as a date through the server and database. For example, PostgreSQL's DATE type stores a calendar date without a time of day. On the way back, parse the value as a date and format it for the person's locale—without converting it through an instant.

On Android, java.time.LocalDate is available from API level 26. If you support older Android versions, check your project's Java API desugaring configuration and supported APIs.

Test the full round trip

A parsing test alone can't catch a conversion hidden in the API, database mapping or UI. Try a test that exercises the actual save and reload path:

In UTC, enter and save 1994-06-12.
Reload it and check that the API returns 1994-06-12 and the screen displays 12 June.
Change the device or test environment to America/Los_Angeles, reload the same record and check both values again.
Repeat with a zone east of UTC, such as Asia/Tokyo, and include dates near year boundaries and a leap day.

For an automated integration test, run the save and reload through your real serialization and persistence layers in each relevant test environment. Inspect what travels over the API as well as what appears on screen; a date-only string can still be converted incorrectly by a client.

Existing timestamp data needs care. Before migrating, establish what the stored timestamps meant and which time zone was used when the original dates were converted. A timestamp alone may not reliably reveal the intended birthday; don't apply a blanket conversion without checking the data and assumptions.

A birthday isn't the only date-only value: a due date or anniversary may be one too. Scheduled meetings and payment events, on the other hand, represent moments and need appropriate time-zone handling. Choose the representation based on what the value means.

References

Disclosure: AI assisted with drafting this article. The example is illustrative.

They closed checkout. That doesn’t mean the payment failed.

Samya — Mon, 26 Oct 2026 15:39:36 +0000

Someone opens the payment screen in your Android app, pauses, then closes it.

The app responds: “Payment failed.”

They may have simply changed their mind. Now the app is telling them something went wrong.

What did Google Play actually return?

Google Play Billing has a response for leaving the purchase flow: USER_CANCELED. Google lists it among the responses that do not indicate an error.

It tells you that the person left without completing the flow. It doesn’t tell you why.

The problem can start with a simple shortcut in the code: treating every non-OK response as a failed payment.

Give cancellation its own branch:

val purchasesUpdatedListener = PurchasesUpdatedListener { result, purchases ->
    setCheckoutLoading(false)

    when (result.responseCode) {
        BillingClient.BillingResponseCode.USER_CANCELED -> {
            recordCheckoutCanceled()
            // Leave the person free to browse. No payment-error alert.
        }

        BillingClient.BillingResponseCode.OK -> {
            handlePurchaseUpdates(purchases.orEmpty())
        }

        else -> {
            handleOtherBillingResponse(result)
        }
    }
}

The helper functions here stand in for your app’s own code. Checkout closes over the browsing screen in this example, so there’s no extra navigation to do.

The purchase checks still belong in handlePurchaseUpdates. Don’t unlock content just because the response is OK: wait for a pending purchase to complete, then verify it before granting access. Google’s purchase-processing guide covers those steps.

Other response codes need their own handling, too. Some call for a retry; others don’t. That’s the job of handleOtherBillingResponse here. This callback is only part of the integration.

The report can get this wrong, too

Even after the warning is fixed, the same mistake can remain in your reports.

If someone backing out counts as “purchase failed” alongside a network problem, you can end up investigating the wrong thing.

You may still want to know how often people leave checkout. Keep that information, but separate it from technical errors.

An outcome such as checkout_canceled is enough to make the difference clear. Record it once for that attempt, without purchase tokens or other sensitive data.

One path worth checking

Open checkout in your test setup, then close it without completing the purchase. This checks leaving a new checkout, not cancelling an existing subscription.

Check that:

The loading state ends.
The person can keep browsing without a payment-error warning.
The report records a cancellation rather than a technical error.
No new access is granted, and any access they already had stays intact.

The app keeps loading. Did my order go through?

Samya — Sun, 25 Oct 2026 07:12:03 +0000

The kitchen has your order. Your phone is still waiting.

Watch the short illustrated example on LinkedIn.

Imagine ordering lunch through an app. You tap Place order, but nothing seems to happen. After a while, you try again.

The server may have saved the first order. Its reply just never reached your phone.

From your side, that looks much like an order that failed. You probably aren't thinking about the server. You want to know whether lunch is coming.

What should happen when you try again?

For this example, say the first request created order 041.

If the app sends the same request again, the server needs a way to recognise it. Otherwise, it might create order 042 as well.

Give each order attempt a unique ID before sending it. Keep that ID if you retry, along with the same order details. The server can then check whether it has already handled that attempt.

This ID is often called an idempotency key.

For an API that supports it, a request might look like this:

POST /orders
Idempotency-Key: 9de69b3a-6ca8-4d9d-a62c-cf34ce127487
Content-Type: application/json

{"cartId":"cart-17"}

The server creates order 041. The reply gets lost. The app retries with the same key and cart, and the server returns order 041.

One detail is easy to miss here: a new key on every retry defeats the purpose. The key belongs to the order attempt, not to each network request.

The header alone won't prevent duplicates, either. The server has to support this behaviour.

Before trusting that retry

There are a few things to check on the server.

Keep the key tied to the authenticated caller. If someone sends the same key with different order details, reject the mismatch or follow the API's documented rules.

Two requests can also arrive together. Both must not pass an “order doesn't exist yet” check and create separate orders. The server needs to handle that race, and a crash must not leave it with an order it has forgotten how to recognise.

Check how long the server remembers a key. After that time, the same key may be treated as a new request. A genuinely new order needs its own key.

There is a phone-side detail too. If someone closes the app while it is waiting, the pending attempt ID and order details need to survive that restart if the app will retry them later.

Disabling the button can help with repeated taps. It won't settle what happened to a request whose reply went missing.

A small test worth trying

Let the server create the order, then drop the reply before the app receives it.

Retry with the same key and order details. Check that the server still has one order and returns that order to the app.

Then send two requests with the same key at once. Also try reusing the key with different details. Those are different cases, and passing the first test doesn't prove the others work.

Stripe documents one implementation of idempotent requests. Its rules for stored results, key expiry and concurrent requests are specific to Stripe, so check the API you actually use.

Back at the lunch counter, the person is still looking at their phone. “Try again” should be a useful next step, not a decision about whether to risk ordering twice.

Your app unlocked the purchase. Did Google Play get the confirmation?

Samya — Fri, 23 Oct 2026 19:02:20 +0000

Someone buys a chapter in your Android app. It opens, and they start reading. From the app screen, the purchase looks finished.

There is one more result to check: did Google Play receive confirmation that your app processed it?

The 30-second illustration shows those two outcomes side by side. It is an example flow, not a recording of a customer purchase.

What can go wrong

For a completed purchase, your app needs to verify the purchase, grant the right access, and tell Play it was processed. If an eligible purchase is left unacknowledged, Play can automatically refund it and revoke the entitlement. A consumable follows a different final step: consuming it also fulfills the acknowledgment requirement. A pending purchase is different again; it should not unlock new access until it becomes PURCHASED.

A test worth running

Use a license tester and a Play test payment method for a non-consumable item. After the purchase completes, check both outcomes:

Can the person open exactly what they bought?
Is the purchase acknowledged in Play, rather than only marked accessible in the app?

Then close and reopen the app. The correct access should still be there, without a second grant or a new purchase prompt. Repeat the exercise for any consumable or pending flow you support; their expected outcomes differ. Play's test-purchase timing is accelerated, so do not use the test refund window as the production deadline.

This small test catches a gap that is easy to miss when you watch only the app screen. It also gives you two concrete places to investigate when a purchase is later refunded: the app's entitlement record and Play's processing state.

References: Google Play purchase processing · Testing Play Billing

Prepared with AI assistance and checked against the linked Google documentation.