Widget: keep the Home-screen widget fresh (publish on background + live battery/connection) (#114)#117
Merged
Merged
Conversation
…+ live battery/connection (#114) The iOS widget snapshot only republished on a FOREGROUND refreshSeq bump (analyze tick / backfill / health sync / .active). Two gaps made it lag the app: - Strap battery % and connection are LIVE state (model.live), not repo-cache, so they never bumped refreshSeq — the widget battery never moved while the app was open ("battery not updating"). Now republished on those changes, foreground-gated (budget-exempt; both low-frequency so no throttle needed). - Nothing republished on the way out, so the widget could show a state older than the user last saw. Now publishes once on background/resign (the app runs bluetooth-central so it isn't suspended; one reload per app-exit is budget-safe). WidgetKit is still a periodic glance in the background (reload budget) — this narrows the app-vs-widget gap, it doesn't make it real-time. The "Charge reads like battery" label + richer illustrations from #114 are separate design calls, not here. StrandiOS target — can't build on WSL; a testing build verifies the Swift compiles.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Addresses the data-staleness half of #114 — the iOS Home-screen widget lagging the app (notably "battery not updating").
Cause
WidgetSnapshot.publishonly ran on a foregroundrefreshSeqbump (15-min analyze tick / backfill completion / health sync /.activetransition). Two gaps:refreshSeq. Strap battery % and connection live onmodel.live, not the repo cache — so while the app was open and battery changed, the widget never refreshed. That's the "battery not updating."Fix
model.live.$batteryPctand$connectedchanges, foreground-gated (.active). Foreground reloads are budget-exempt, and both are low-frequency (battery ~8 min, connection flips rare), so no throttle needed.bluetooth-central(not suspended in background), so this executes; one reload per app-exit is well within WidgetKit's daily budget.Honest scope
WidgetKit is still a periodic glance in the background (hard reload budget) — this narrows the app↔widget gap, it doesn't make the widget real-time. Out of scope (separate design calls, not built here): the "Charge" label reading like battery-charge, and the richer illustrations / layout the reporter also asked for. Also worth noting for the reporter: on a WHOOP MG several of these (Charge/HRV) are often No Data/calibrating, so some apparent "inaccuracy" may be the strap, not the widget.
Testing
StrandiOS target — can't build on WSL; a testing build verifies the Swift compiles. Ideally confirmed on-device (widget updates on battery change + after backgrounding).
File:
StrandiOS/App/StrandiOSApp.swift.