Resume unsaved feature edits after unexpected app closure

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 specifications

When to surface the prompt

1. When opening the project that contains the unsaved changes (not on app open)
   Use a notification (with a 10 second timeout) so the user can still see the map before deciding what to do:

You have unsaved changes. Tap here to open them

Tapping on the notification reopens either the geometry capture or the feature form, depending on the unsaved state of the new feature/ edited existing feature.
Tapping on the close button, discards the notification

2. When tapping on the Add button or when entering Edit mode for an existing feature in the project that contains the unsaved changes:
   Use a warning drawer that notifies the user that there were some unsaved changes.

• title: Depending whether the previous feature was new or already existing the drawer should contain: You have unsaved changes or You have unsaved changes on feature name of the feature
• description: The app closed before saving your changes on layer name, click resume to start editing them again. If not, click discard.
• Resume editing button: this button takes you to resume the geometry capture or filling the feature form, depending on the unsaved state of the previous feature.
• Discard unsaved changes: this button takes you to a confirmation drawer that double checks if the user wants to truly dismiss the unsaved changes. The confirmation drawer has 2 buttons:
  Discard changes, that discards the unsaved changes and takes user to either Add or Edit a feature, depending on the action that triggered it in the first place.
  Do not discard, that closes down the drawers, but does not discard the unsaved changes, returns to the map.

for both the warning and confirmation drawer, tapping on the close button takes them back to the map and doesn’t discard the changes

3. When navigating to the layers of the project that has unsaved changes
   An information banner will be on top of the layers list that informs the user that layer name has unsaved changes. This banner has a Resume button that takes you to resume the geometry capture or filling the feature form, depending on the unsaved state of the previous feature.

4. When navigating to the layer where the previous feature’s changes where unsaved
   An information banner will be on top of the feature list that informs the user that There is an unsaved feature or, if the feature previously existed, Unsaved changes on feature name. This banner has a Resume button that takes you to resume the geometry capture or filling the feature form, depending on the unsaved state of the previous feature.

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 (Edited) --> moved to V2

⚠️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: https://www.figma.com/design/d78a4ehBBgK6MyxCTuCAqg/Mobile-App?node-id=7259-729&t=rHlTGRI0UDfzoXDc-4