A field worker may finish recording a large video just as connectivity drops. Restarting the entire upload wastes time and data, but displaying a completed attachment too early is worse. Define what the server has accepted and what the user can safely recover.
Related service: Mobile application development- 01Create an authorized upload session.
- 02Transfer and acknowledge data.
- 03Persist the upload reference.
- 04Reconcile progress after interruption.
- 05Validate and attach the completed file.
SECTION 01
Agree the upload contract with the backend
The app and server must agree on file identity, accepted size and type, progress reporting, expiry and completion. The tus resumable-upload protocol illustrates using a server-confirmed offset to continue an interrupted transfer. You can use a supported storage-provider mechanism instead, but the same buyer question remains: which progress can actually be trusted after a connection fails?
Ask how the app detects a changed local file or an upload session belonging to another account. Credentials should not be embedded permanently in a public file URL. Android's background-work guidance also makes clear that operating-system restrictions affect when tasks can run. Do not promise uninterrupted uploading after every kind of app closure or device event.
SECTION 02
Illustrative example: an interrupted equipment video
Suppose a technician uploads a sample inspection video from a weak connection. The connection fails after some data reaches storage. On return, the app asks the server what it has accepted rather than trusting its last local progress display. It resumes the same session if that session and the original file are still valid.
The file finishes transferring but has not yet passed the agreed validation. Show processing rather than attaching a broken or unsafe object as ready for review. If the session expired, explain why a new upload is required and retain the technician's report draft. This is an illustrative workflow, not a guaranteed behavior of every storage service.
SECTION 03
Test recovery at more than one boundary
Commission tests for lost acknowledgement, repeated resume requests, a moved local file, low storage, expired authorization and logout during upload. Verify that retries do not create several attachments for one intended file. Define who may cancel an upload and what happens to partially stored objects after cancellation or expiry.
Handoff should include supported limits, background behavior, cleanup responsibility and a traceable upload reference for support. A simple foreground transfer may be sufficient for small files; resumable large-file handling adds backend state and operational work. Choose it because interrupted transfers are a real user problem, not because a moving progress indicator makes the feature appear complete.
SECTION 04
Frequently asked questions
Can all uploads continue after force-closing the app?
Do not assume so. Platform and task restrictions vary; test and document the supported behavior for the chosen implementation.
What if the original file changes?
The app must detect the mismatch and avoid combining bytes from different files. It may need to create a new upload session.
When is the attachment ready?
After the agreed server completion and validation steps succeed, not merely when the phone has attempted to send all bytes.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Resumable upload protocoltus
- Background task constraintsAndroid Developers
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy