feat(ios): measure the Live Activity's progress over the stretch it is shown for - #175
Merged
Merged
Conversation
…s shown for The work countdown is published only for the last 5, 15 or 30 minutes of a shift. Measured against the whole day, its bar arrives about 97% full and crawls the last three points before clock-off: it looks broken, and it spends the card's only bar restating what the digits above it already say better. Both meters now span the activity's own life — from the moment it was scheduled to appear to the end it is counting to. The payload carries that instant as `displayStartAtMs`, because the extension has no idea what lead time the user picked. The segments are the same effective ones, only clipped, so lunch still does not count and the bar still holds still across it. Overtime needs no special case: the rules bundle already extends the last segment when it is added, so the window grows with it instead of sitting full for the extra time. The percentage in the expanded island moves with the bar, because a meter and a number side by side that disagree are worse than either alone. `projectedProgress` stays as it is for payloads with no window — focus legs, and activities written by an older build — and its habit of taking the shift's own progress as a floor is exactly why the window needed its own function: 96.9% as a floor pins a fifteen-minute bar full from the first frame. `AppTests/LiveActivityWindowTests` pins all of it: the clip, the lunch gap inside a window, overtime, the missing floor, and the fallbacks. Six tests, run serially, all passing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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.
This is
a29ec01, which was pushed to #174's branch 45 minutes after #174 had already merged, so it never reached main. Same commit, cherry-picked onto current main. Reported from a device: adding overtime still showed a whole-shift bar, with the lunch pause in it.What changes
The work countdown is published only for the last 5, 15 or 30 minutes of a shift. Measured against the whole day, its bar arrives ~97% full and crawls three points before clock-off — it looks broken, and it spends the card's only bar restating what the digits above it already say better.
Both meters — the lock-screen bar and the minimal island's ring — now span the activity's own life: from the instant it was scheduled to appear to the end it is counting to. The payload carries that instant as
displayStartAtMs, because the extension does not know which lead time the user picked.projectedProgressis untouched for payloads with no window — focus legs, and activities written by an older build. Its habit of taking the shift's own progress as a floor is precisely why the window needed its own function: 96.9% as a floor pins a fifteen-minute bar full from the first frame.Checks
AppTests/LiveActivityWindowTests— 6 tests,-parallel-testing-enabled NO, all passing, re-run on this rebase because it is the first time this change and fix(ios): show whole minutes, not "8:--", on the dimmed lock screen #173 have been built together. They pin the clip, a lunch gap inside a window, overtime, the missing floor, and both fallbacks.npm run check:iospasses.Two runs before that one reported
The test runner hung before establishing connection.— a stale manually-installed app on the simulator, not a source failure. Uninstalling it and rebooting the simulator cleared it.Note for merging
An activity that is already running when the app updates keeps its old payload and therefore its old whole-shift bar until the next reschedule. Testing this wants a fresh shift rather than the one on screen.
🤖 Generated with Claude Code