State Management

State management on mobile is two questions wearing one name. The first is the familiar one: which screens need to see the same data, and how do they stay in agreement. The second is specific to devices: what survives when your app stops running.

The first question has the answers you already know — keep state close to where it is used, lift it when two screens need it, and have one source of truth for anything a user can change. Those apply unchanged here.

The second question is the one that catches people, because the failure is invisible during development. You run the app, you use it, everything works. Then a real user switches to their camera for four minutes and comes back to an empty form.

Termination is not an error condition. It is routine memory management, and it happens more on older and cheaper devices, which is to say the devices many of your users actually have. An engineer's phone with a mapping app, a camera, a messaging app and a browser open is a device under pressure, and your backgrounded app is a reasonable thing for the system to reclaim.

So the design question becomes: what would the user be upset to lose? Sort state into three tiers and the answer stops being a judgement call every time.

interface VisitDraft {
  employeeId: number;
  notes: string;
  screen: string;
  updatedAt: number;
}

interface KeyValueStore {
  read(key: string): Promise<string | null>;
  write(key: string, value: string): Promise<void>;
  remove(key: string): Promise<void>;
}

const DRAFT_KEY = "restore.visitDraft";
const MAX_AGE_MS = 1000 * 60 * 60 * 12;

/** Called when the app moves to the background, not on every keystroke. */
export async function saveDraft(store: KeyValueStore, draft: VisitDraft) {
  await store.write(DRAFT_KEY, JSON.stringify(draft));
}

export async function restoreDraft(
  store: KeyValueStore,
  now: number,
): Promise<VisitDraft | null> {
  const raw = await store.read(DRAFT_KEY);
  if (raw === null) return null;

  try {
    const draft = JSON.parse(raw) as VisitDraft;
    if (typeof draft.notes !== "string" || !Number.isInteger(draft.employeeId)) {
      return null;
    }
    if (now - draft.updatedAt > MAX_AGE_MS) return null;
    return draft;
  } catch {
    await store.remove(DRAFT_KEY);
    return null;
  }
}

• Read this as a shape. Every platform has a small key-value store and a way to be told the app is backgrounding; the names differ and the sequence does not.
• Writing on background rather than on every keystroke is deliberate. Per-keystroke writes cost battery and wear, and the background moment is the one point where you know the state is worth capturing. If a note takes several minutes to write, add a timed save every twenty or thirty seconds as well — the background callback is not guaranteed to complete.
• The stored value is validated, not trusted. It was written by an earlier version of your own app, possibly one with a different field layout, and it may have been cut short if the process ended mid-write. A parse failure is an ordinary outcome, so the catch clears the bad value instead of crashing on launch.
• The age check exists because a restored draft has to be plausible. Offering someone yesterday's half-written note as though they were mid-sentence is confusing, and twelve hours is a defensible line for an app used on shift. Pick your own number and say why in a comment.
• Restoring a screen name and its parameters is what makes continuation feel seamless. Restore into a validated state, though: if the employee record has since been deleted, land on a screen that explains that rather than one that immediately fails to load.