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
Top comments (0)