Resume unsaved feature edits after unexpected app closure

[tomasMizera]

Current behavior

When a user starts capturing or editing a feature, the mobile app only stores geometry and attributes after they tap Save in the feature form. If the app closes before that point — due to a crash, an incoming call, or a dead battery - all progress is lost and the user has to start again from scratch.

Goal

Store feature edits (geometry and attributes) in persistent storage as the user
works, so they can recover and continue if the app closes unexpectedly.

Example scenarios

1. App closes during geometry capture

1. Start adding a new line or polygon feature
2. Add a couple of vertices
3. App closes (crash, call, battery)
4. Reopen the app
   • Current: user starts from scratch
   • Expected: app prompts the user to continue editing the previous feature

2. App closes while filling in the feature form
Same as above, but the app closes while the feature form is open with unsaved
attribute changes.

UX specification

When to surface the prompt

The draft prompt is triggered on entering the project that contains the
draft - not on app open. At that point the user is in the right context, the
map is visible, and the prompt is immediately meaningful.

Use a persistent banner (not a modal) so the user can still see the map
before deciding. Suggested copy:

You have an unsaved [geometry type] on [Layer Name]. Want to continue?
Resume · Discard

Tapping Discard requires a single confirmation before the draft is deleted
permanently. The draft is never surfaced again after explicit dismissal.

Recovery flow

The app restores the user to the exact stage they were at when the app closed

• geometry capture or attribute form - without requiring them to navigate back
  manually.

Validation before recovery

Before offering recovery, validate the draft against the current layer state.
Discard silently (no prompt) if any of the following are true:

• The layer no longer exists in the project
• The layer schema has changed (field added, removed, or type changed)
• The feature ID no longer exists (for edits to existing features)
• Draft is older than 10 days

1-n relationship features — behaviour TBD

⚠️ Decision needed before implementation.
The intended behaviour for draft recovery when the user is adding child
records via a relationship form has not been finalised. This includes how
the in-progress child feature should be stored, and how recovery should
behave when the parent has already been committed to obtain its primary key.
Resolve this before development starts or explicitly defer to v2.

Technical notes

• Use QSettings to implement the drafts mechanism
• Store QgsFeature (geometry + attributes) and the vector layer ID, scoped
  per project, whenever a feature form is open in add and edit mode
• Update the draft on any geometry or attribute change - apply a 1-second
  debounce to avoid excessive writes
• Discard the draft once a layer commit succeeds or user closes feature form without saving changes

Resources

• Wishlist request: Persist data in record that was being entered when Mergin mobile app crashes
• Design: TBD