Long forms are especially frustrating on a phone when a call, app restart or lost connection erases the work. Preserving a draft helps, but it must not make users believe that an incomplete or unsent form has reached the business.
Related service: Mobile application development- 01Create or restore an owned draft.
- 02Save progress with a visible state.
- 03Explain fields needing correction.
- 04Submit an identified attempt.
- 05Confirm server acceptance or preserve recovery.
SECTION 01
Decide which interruptions the draft survives
Specify whether the draft survives navigation, rotation, system process termination, device restart or logout. These are different events. Android's state-saving guidance distinguishes temporary interface state from persistent application data; a long-lived business draft should not rely only on an in-memory screen object.
Choose when progress is saved and how the user can tell. If saving fails because storage is unavailable, keep the message visible and offer a safe next step. OWASP's mobile storage guidance also applies to sensitive drafts. Define account separation, device storage protection and expiry rather than keeping private forms indefinitely in a shared location.
SECTION 02
Illustrative example: an interrupted site survey
Imagine a worker records a sample site survey with notes and several measurements. A phone call interrupts the task. On return, the app restores the draft and clearly marks it as not submitted. Missing required measurements can remain in a draft; forcing every field to validate before any progress is saved would defeat the purpose.
The worker later submits on a weak connection and receives no acknowledgement. The app should check the identified attempt or offer a safe retry, not create another survey blindly. If the server rejects an outdated form version, preserve the draft and explain which fields need review. This is a planning scenario, not a delivered-client claim.
SECTION 03
Test the transition to an accepted record
Ask the agency to show incomplete drafts, failed saves, expired sessions, attachment failures and server-side validation errors. Error messages should identify the affected fields without discarding unrelated entries. Keep client-side convenience checks, but do not rely on them as the authority for permissions or business rules.
Agree what happens when the same person edits on another device and whether cross-device draft sync is included. That is additional scope, not an automatic property of local saving. Handoff should document draft cleanup, supported recovery events and the meaning of every status. A concise, honest status message is more valuable than an always-green Saved label that hides failed persistence or an uncertain submission.
SECTION 04
Frequently asked questions
Can a draft contain invalid or incomplete fields?
Usually yes, within safe storage limits. Submission can require additional checks while drafting preserves unfinished work.
Does saving on one phone synchronize every device?
Not necessarily. Cross-device synchronization needs an explicit backend and conflict-handling scope.
When should the app say submitted?
When the agreed backend acceptance is confirmed. Local saving or a queued network request should have a different status.
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.
- Interface state and persistent storageAndroid Developers
- Secure mobile storageOWASP Foundation
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