You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feature bug: Live Activity display has truncation problems #593
The new Live Activity feature, currently found in dev, has some truncation issues.
This issue includes a screenshot of one such issue.
For this case the scheduled basal of 0.65 U/hr is visible but the full string: "0.65 -> 0" is truncated so the currently applied Temporary Basal Rate is not visible.
Would it make sense to only show the current/effective basal in this view? Given the space constraints, that might be clearer than trying to display both values and risking truncation.
Given the space constraint, the idea that we only show effective basal on the Live Activity makes sense.
I'll first play around with the size. I think we can increase each cell’s width (e.g., 60 → 72) and allow the value text to shrink more aggressively (minimumScaleFactor ~0.65 + allowsTightening(true)), while slightly reducing the left column width to free space.
If this preserves the aligned 2×2 matrix but gives each slot enough flexibility to avoid truncation, I'll keep it. Otherwise, I'll fall back on only showing the effective basal.
I don't have an iPhone SE I can test the visual on, though. I can test on an iPhone 17, which is 1.6 inches wider.
Activity
marionbarker commentedon Apr 9, 2026
We had similar issues with Loop.
This PR was added to assist in truncation for larger fonts.
bjorkert commentedon Apr 9, 2026
Would it make sense to only show the current/effective basal in this view? Given the space constraints, that might be clearer than trying to display both values and risking truncation.
MtlPhil commentedon Apr 18, 2026
Given the space constraint, the idea that we only show effective basal on the Live Activity makes sense.
I'll first play around with the size. I think we can increase each cell’s width (e.g., 60 → 72) and allow the value text to shrink more aggressively (minimumScaleFactor ~0.65 + allowsTightening(true)), while slightly reducing the left column width to free space.
If this preserves the aligned 2×2 matrix but gives each slot enough flexibility to avoid truncation, I'll keep it. Otherwise, I'll fall back on only showing the effective basal.
I don't have an iPhone SE I can test the visual on, though. I can test on an iPhone 17, which is 1.6 inches wider.
MtlPhil commentedon Apr 18, 2026
Will test with longer basal string. If it doesn't work on a smaller screen, let's do only effective basal.
marionbarker commentedon Apr 26, 2026
closed with merge of #610