This is a feature I would love to see this implemented; the ability to cancel a notification (or even whole category).
As an example where his would be really handy for me, every time I arrive home, I have a notification asking me if I want to open the roller door, and one warning me if it's left open. This is handy if I'm in a different car/bike, but most of the time I just use the an RF remote to open the door. As a result, my phone builds up endless notifications related to the roller door.
Ideally, once this notification is sent, I'd like to be able to cancel it once the roller door is opened.
Easy enough, will try to sneak it in for 2.0.
Related: #215
Hey there,
I've found #544 and checked out the other issues linked here, e.g.
Is there any example on how to clear a notification on iOS?
Do I have to replace an actionable notification with a non-actionable notification as messages can only be replaced but not deleted?
Thanks in advance.
Any update about this? I couldn't understand the decision :/
Consolidating points from several notification threads as far as I have an overview:
It IS already possible to replace existing notifications with new notifications using apns-collapse-id (See Companion Docs)
It IS NOT YET possible to completely remove existing notifications, i.e., not replacing them with a new notification but removing it from the Notification Center all together. The SDK does have a method for this removeDeliveredNotifications (Docs), so this may be possible.
Maybe we can clarify this PR, or alternatively reuse #579 since it appears to be more targeted to the addition of the second point, rather than this broader feature request which incorporates both 1) and 2)
Wdyt, @robbiet480?
Spent some more time investigating this, and I don't think it can be reliably done via an on-device solution. I think the only path forward is to try and figure out a "blessed" way to do this directly with APNS that doesn't involve the app running.
Approach 1: use the Notification Service Extension to remove the notification.
This can successfully remove notifications using removeDeliveredNotifications(withIdentifiers:). In fact, it looks like the request identifier when using apns-collapse-id is the same as the collapse-id (at least at the time of testing this on iOS 14) so either Firebase or Apple are doing some of the heavy lifting there.
However, there's a rather _large_ caveat here: the extension can only be executed for a notification with content (e.g. a message) and there doesn't exist a mechanism to remove the one that's about to be delivered. I'm guessing that Apple has thought through this scenario and is active preventing it. For example, attempting to remove the being-delivered notification after some number of seconds after finishing it is never successful.
Approach 2: use silent notifications, like clear_badge and request_location_update
clear_badge uses a silent message with a badge value of 0, which will always work to clear the notification since it's a feature of the push notifications directly.request_location_update relies on the app being woken up as a result of the incoming notification before it will do any work. When we rely on the silent notification waking the app (like with request_location_update) there stands to be a pretty good chance that it won't happen: the device limits how often and at what time the notification will launch the app to execute the request. Since we do know the identifier (via the collapse id), it is possible to make this (when it actually runs) remove notifications, but we cannot be confident it will actually get woken up to do the removal.
Given the above, I do not think an unreliable "clear notification" command is a significant improvement on replacing existing notifications using the existing collapse id feature, so I think we'll need to continue researching before this can be done.
Thanks for looking at this!
However, there's a rather _large_ caveat here: the extension can only be executed for a notification with content (e.g. a message) and there doesn't exist a mechanism to remove the one that's about to be delivered. I'm guessing that Apple has thought through this scenario and is active preventing it. For example, attempting to remove the being-delivered notification after some number of seconds after finishing it is never successful.
I'm ok with that limitation and don't see it as much of a problem for myself. My primary use case is to clean up notifications like "garage door left open" once it is no longer the case.
If you wish to clean up notifications to make their state more clear, you can use the collapse id to replace them. The part you quoted is more-or-less saying that it cannot both remove an item _and_ prevent the command to remove from displaying. If you're fine with still having a notification on the lock screen, sending a replacement with collapse id is your best route.
If you wish to clean up notifications to make their state more clear, you can use the collapse id to replace them. The part you quoted is more-or-less saying that it cannot both remove an item _and_ prevent the command to remove from displaying. If you're fine with still having a notification on the lock screen, sending a replacement with collapse id is your best route.
This is my current approach, just to share it: When the garage door was closed after having been deemed to have been left open for too long I send a notification to that point which then replaces the prior notification(s) (about having left the door open).
Ok. I guess I didn't understand what was meant by "to remove the one that's about to be delivered".
Most helpful comment
Consolidating points from several notification threads as far as I have an overview:
It IS already possible to replace existing notifications with new notifications using
apns-collapse-id(See Companion Docs)It IS NOT YET possible to completely remove existing notifications, i.e., not replacing them with a new notification but removing it from the Notification Center all together. The SDK does have a method for this
removeDeliveredNotifications(Docs), so this may be possible.Maybe we can clarify this PR, or alternatively reuse #579 since it appears to be more targeted to the addition of the second point, rather than this broader feature request which incorporates both 1) and 2)
Wdyt, @robbiet480?