Should typing a draft and publishing it use the same coroutine scope?

Answer

Start with user expectations. Leaving the editor can cancel suggestions or a live preview. After the user confirms Publish, they may expect delivery to continue even if the screen disappears.

A ViewModel scope is appropriate for work tied to its owner. It survives ordinary configuration changes but is cancelled when the ViewModel is cleared, and it cannot survive process termination. An application-owned coroutine scope also disappears with the process.

For a publish operation that must be retried across process restarts, first persist a pending operation and its content, then schedule suitable persistent work. Show pending, sending, failed, and sent states from stored operation data. WorkManager is a candidate for deferrable persistent work; it is not a promise of immediate execution.

Design exercise

Sketch this sequence:

Copy codeConfirm Publish
  -> persist draft revision + operation ID
  -> enqueue delivery work
  -> display pending status
  -> reconcile server acknowledgement

If the app stops between persistence and enqueueing, a reconciliation pass should find unscheduled pending operations. Delivery needs an idempotency strategy because recovery can schedule it again.

Follow-up to practise

Can the user edit while publishing? Capture a specific revision for the pending operation. Otherwise the worker could upload content different from what the user approved. Define whether later edits create a new revision or replace an unsent one.

References

Android Developers: Lifecycle-aware coroutines

Android Developers: Persistent background work