DEV Community

Lynavo
Lynavo

Posted on

The State Machine Behind Honest Automatic Backup

#localfirst #automation #opensource #architecture

A settings screen may represent automatic backup as one boolean:

automaticBackup = true
Enter fullscreen mode Exit fullscreen mode

The real system is closer to a state machine.

A transfer cannot start just because a toggle is on. The user may not have selected a destination. The phone and computer may be on different networks. The computer may be asleep. The mobile app may no longer have permission to continue in the background.

When we collapse all of those conditions into one toggle, users experience the missing state as a vague failure: “Automatic backup is on, so why did nothing happen?”

Model readiness instead of intent

The toggle records intent. It does not prove readiness.

An illustrative model might look like this:

type BackupContext = {
  enabled: boolean
  destinationSelected: boolean
  phoneAndComputerShareLan: boolean
  computerReachable: boolean
  foregroundActive: boolean
  backgroundTransferAvailable: boolean
}

type BackupState =
  | "disabled"
  | "needs-destination"
  | "waiting-for-local-network"
  | "waiting-for-computer"
  | "paused-in-background"
  | "ready"

function deriveBackupState(ctx: BackupContext): BackupState {
  if (!ctx.enabled) return "disabled"
  if (!ctx.destinationSelected) return "needs-destination"
  if (!ctx.phoneAndComputerShareLan) return "waiting-for-local-network"
  if (!ctx.computerReachable) return "waiting-for-computer"

  if (!ctx.foregroundActive && !ctx.backgroundTransferAvailable) {
    return "paused-in-background"
  }

  return "ready"
}
Enter fullscreen mode Exit fullscreen mode

This is an explanatory model, not LynavoDrive production source code. The useful idea is the separation between what the user asked for and whether the system can currently do it.

Make every blocking state explainable

Each non-ready state should answer three questions:

  1. What is blocking the operation?
  2. What can the user do now?
  3. Will the system resume automatically when the condition changes?

For example:

State Weak message Useful message
Different networks Connection failed Connect the phone and computer to the same local network.
Computer asleep Device unavailable Wake the computer and keep the desktop app connected.
Background unavailable Nothing Transfer paused when the app left the foreground.
Destination missing Setup incomplete Choose a computer folder before enabling backup.

The message should not promise automatic recovery unless retry behavior has been implemented and tested.

Public internet and a local network are different dependencies

“Wi-Fi required” is often too vague for device-to-device software.

A product can need public internet during account setup or initial connection while later moving files directly between devices on the same local network. A phone may also display a Wi-Fi icon while connected to a guest network that isolates local devices.

Treat these as distinct capabilities:

type Connectivity = {
  publicInternetAvailable: boolean
  localPeerReachable: boolean
}
Enter fullscreen mode Exit fullscreen mode

The UI should tell the user which one is missing. Otherwise, people troubleshoot the router when the account service is unavailable, or troubleshoot the internet connection when the devices simply cannot see each other locally.

Background execution is a product boundary

On mobile platforms, background work is constrained by operating-system policy, battery management, permissions, and the product's own plan or implementation.

That means “automatic” and “continues in the background” are separate claims.

If a transfer pauses when the app leaves the foreground, expose that state. If screen-off transfer is available only in a particular edition, disclose it next to the automatic-backup control. Do not let a marketing label imply a runtime guarantee the system does not provide.

A current product example

I am part of the team building LynavoDrive, an open-source phone-to-computer backup and file-access tool.

Its current local photo-backup workflow has explicit conditions:

  • the user enables Automatic Backup first;
  • the phone and computer share the same local network;
  • the computer remains powered on and connected;
  • initial setup needs internet access;
  • after setup, the local workflow can operate on the same LAN without public internet;
  • screen-off and background transfer are subscription features.

The workflow is backup-oriented rather than complete two-way folder sync. Phone and computer deletions are independent.

Those conditions are not implementation trivia. They are part of the product contract.

The engineering checklist

Before shipping a feature labeled “automatic,” verify that the product can answer:

  • What one-time action enables it?
  • What permissions are required?
  • Does it need public internet, local reachability, or both?
  • Which destination device must remain online?
  • What happens in the foreground, background, and screen-off states?
  • How is a blocked or failed operation surfaced?
  • Which changes resume automatically, and which require user action?
  • Does deletion propagate, or are copies independent?

An automation feature is trustworthy when users can tell both why it is working and why it is not.

You can inspect the open-source local core and documentation for LynavoDrive at https://github.com/Lynavo/lynavo-drive.

Disclosure: I am part of the LynavoDrive team. AI tools assisted with drafting; the technical examples and product boundaries were reviewed before publication.

Top comments (0)