Fix TRC bolus command not received by Trio#589
Fix TRC bolus command not received by Trio#589rafaeldelrey wants to merge 1 commit intoloopandlearn:devfrom
Conversation
Switch TRC push notifications from alert to background type. Alert-type pushes are silently dropped by iOS when Trio has not been granted notification permissions. Background push with content-available: 1 and priority 5 is delivered regardless, which is the correct mechanism for remote command delivery.
| init(encryptedData: String, commandType _: TRCCommandType) { | ||
| self.encryptedData = encryptedData | ||
| aps = APSPayload(alert: "Remote Command: \(commandType.displayName)") | ||
| aps = APSPayload() |
There was a problem hiding this comment.
This article says background notifications should not contain alert: developer.apple.com/documentation/usernotifications/pushing-background-updates-to-your-app
|
Thanks for your interest in this. Trio Remote Commands was originally implemented as a plain background push message, but due to the nature of how those work it was far from reliable — it works in good conditions, but otherwise the message might be delayed or not delivered at all. User reports were that too many messages didn't get through in time. In a recent change we moved to the current implementation (which also aligns with Loop/Loop Caregiver), and the success rate is much higher — user feedback supports this. The case I think you're really getting at — messages not arriving when notifications are off for Trio — is better handled with a PR towards Trio itself: when remote commands are enabled, detect if notifications are disabled and require them to be turned on. If the notifications are disturbing, the sound option can be turned off for Trio notifications in iPhone Settings. I'm closing this one, but feel free to comment anyway. |
2 participants
Summary
apns-push-type: alert(priority 10) toapns-push-type: background(priority 5)alertandinterruption-levelfields from the APNS payloadProblem
Remote bolus commands sent via Trio Remote Control appeared to succeed (APNS returned 200) but Trio never received or acted on them. Trio's logs showed no trace of an incoming push notification.
The root cause: when
apns-push-type: alertis used, iOS silently drops the notification if the receiving app (Trio) has not been granted notification permissions by the user. The command never reachedAppDelegate.didReceiveRemoteNotification.Fix
Background push notifications (
content-available: 1,apns-push-type: background, priority 5) are delivered by iOS regardless of notification permission status, which is the correct mechanism for remote command delivery. This matches Apple's documentation requirements — priority 5 is mandatory when usingapns-push-type: background.Test plan