Эквивалент ключа сворачивания push-уведомлений Apple

Начиная с iOS 10 и используя API HTTP/2.0 APNS, вы можете указать заголовок apns-collapse-id и обрабатывать логику свертывания в своем приложении.

Свернутые уведомления будут отображаться как одно уведомление на устройстве, которое постоянно обновляется новыми данными. Каждый раз, когда уведомление обновляется, оно перемещается в верхнюю часть ваших непрочитанных уведомлений.

Описание apns-collapse-id взято с сайта https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingwithAPNs.html:

Несколько уведомлений с одинаковым идентификатором свертывания отображаются пользователю как одно уведомление. Значение не должно превышать 64 байта. Дополнительные сведения см. в разделе Качество обслуживания, промежуточное хранение и объединенные уведомления.

и из https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW1:

Когда устройство подключено к сети, все отправляемые вами уведомления доставляются и становятся доступными для пользователя. Однако вы можете избежать отображения повторяющихся уведомлений, используя идентификатор свертывания для нескольких идентичных уведомлений. Ключ заголовка запроса APNs для идентификатора свертывания — apns-collapse-id, он определен в таблице 6-2.

Например, служба новостей, которая отправляет один и тот же заголовок дважды подряд, может использовать один и тот же идентификатор свертывания для обоих запросов push-уведомлений. Затем APN позаботится об объединении этих запросов в одно уведомление для доставки на устройство.

В iOS 10 появился новый «apns-collapse-id», который, похоже, справится с такой задачей. Если у вас есть учетная запись разработчика Apple, вы можете посмотреть видеоролики сеанса уведомлений WWDC 2016 (вступительное видео 707 https://developer.apple.com/videos/play/wwdc2016/707/).

Ответ Doody P работает для удаленных уведомлений, но есть также эквивалент для локальных уведомлений: когда вы создаете свой UNNotificationRequest, вы можете установить identifier на то, что вы использовали в качестве ключа свертывания. После срабатывания push-уведомления будет отображаться только последняя версия, которую вы отправили с этим идентификатором.

(Мы автоматически отправляем push-уведомления через APN, а затем повторно запускаем их как локальные уведомления, потому что нам нужно убедиться, что наши пользователи вошли в систему.)

В этом докладе WWDC есть удобные примеры кода и демонстрации управления доставленными уведомлениями. - ключевой раздел с ~18:00 до 21:00.

Если APN пытается доставить уведомление, но устройство находится в автономном режиме, уведомление сохраняется в течение ограниченного периода времени и доставляется на устройство, когда оно становится доступным.

Хранится только одно недавнее уведомление для определенного приложения. Если несколько уведомлений отправляются, когда устройство находится в автономном режиме, каждое новое уведомление приводит к отбрасыванию предыдущего уведомления. Такое поведение, при котором сохраняются только самые новые уведомления, называется объединением уведомлений.

https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html

Так что в iOS нет необходимости в collapse_key.

К вашему сведению, collapse_key полезен только тогда, когда устройство отключено/неактивно:

Этот параметр определяет группу сообщений (например, с Collar_key: «Доступные обновления»), которые можно свернуть, чтобы при возобновлении доставки отправлялось только последнее сообщение. Это сделано для предотвращения отправки слишком большого количества одинаковых сообщений, когда устройство возвращается в сеть или становится активным (см. delay_while_idle).

https://developers.google.com/cloud-messaging/server-ref#downstream

ОБНОВЛЕНИЕ:

Как для iOS, так и для Android (с помощью функции crush_key), если устройство находится в автономном режиме (т. е. сервер push-уведомлений Apple/Google не может связаться с ним), сервер push-уведомлений перезаписывает все предыдущие уведомления, и сохраняет только последний.

Если устройство подключено к сети, то, я думаю, вы можете делать с полученным уведомлением все, что хотите. По крайней мере, в Android вы можете решить, хотите ли вы «складывать вещи», хотите ли вы перезаписать любое предыдущее уведомление в области уведомлений или хотите ли вы перезаписать любое предыдущее уведомление того же типа.

NotificationManager notificationManager = ...;
String appName = ...;
NotificationCompat.Builder builder = ...
// Always use the same id, so only the last notification will be displayed in the notification area.
int notId = 0;
// Always use a different id, so all notifications will pile up in the notification area
notId = new Random().nextInt(100000);
// Uses the type of notification as id, so you'll only have up to one notification per type
// in the notification area. It's like using collapse_key, but on the app itself.
// That type should should be some additional data in the notification you sent.
notId = notificationType;
Notification notification = builder.build();
notificationManager.notify(appName, notId, notification);

В iOS такой функции нет. Однако, поскольку push-уведомления отправляются сервером, который находится под вашим контролем, вы можете отслеживать, какие уведомления вы отправили на конкретное устройство, и решать, отправлять ли новые. Другими словами, вы помещаете логику в код сервера, а не в код приложения для iOS.