Skip to content

Fallback Execution Brainstorm

Goal

Explore options for maintaining dosing execution or safe fallback behavior when BLE connections are lost (G7, DASH), including Live Activity UX, scheduling, and pump history reconciliation.

Hard Constraints

  • If both G7 and DASH are out of BLE range, the app cannot reliably fetch fresh CGM data or confirm pump status/delivery.
  • In that condition, algorithm stepping must be treated as unavailable (no safe doWork execution path).
  • Live Activity or background timers do not remove this data/connectivity constraint; they only improve user awareness and recovery workflow.

Notes

  • Live Activities are primarily for user-visible, time-sensitive updates; they are not a background execution mechanism.
  • A Live Activity can keep the app “active” while visible, but it does not guarantee continuous execution if the system suspends the app.
  • This would be a best-effort safety aid, not a primary execution strategy.

Potential Uses

  • Display current loop status, last successful algorithm run, and BLE connection state.
  • Provide a “Reconnect devices” action that deep-links into the app.
  • Surface a timer since last CGM read or pump status update.
  • Reconcile missed delivery using OmniBLE pump history events after reconnect (use dosesForStorage → NewPumpEvent).

Proposed Fallback State Model

  • Normal: CGM + pump channels available; 5-minute algorithm stepping active.
  • Degraded: intermittent channel loss; allow reconciliation/status refresh on wake events, but run only when freshness/readiness gates pass.
  • Offline: both channels unavailable or outage threshold exceeded (for example >= 15 minutes); no algorithm step execution, explicit user notification.
  • Recovery: connectivity restored; reconcile pump history first, then resume normal step gating.

Open Questions

  • What iOS background modes and system conditions allow periodic refresh while a Live Activity is visible?
  • Is it acceptable (clinically and from UX) to prompt the user to keep the Live Activity visible during disconnections?
  • How does this interact with BGTaskScheduler and BLE background updates already in use?

Next Steps

  • Prototype a minimal Live Activity status card (loop state + BLE status).
  • Validate behavior on test device during simulated BLE disconnects.
  • Define exact offline entry/exit thresholds and alert copy, then mirror them in Docs/Planning/DevChangePlan.md timing requirements.