Skip to main content
Utilisez ce guide pour comprendre et contrôler ce qui arrive à vos notifications push après leur affichage sur un appareil : ce que font le clic et le rejet, quand Android réaffiche les notifications, comment les badges restent synchronisés, et quels outils du SDK vous permettent de gérer la barre depuis le code de votre application. Cette page couvre le push mobile (Android et iOS). Pour le comportement du web push, consultez Comportement des notifications web push.

​
Cycle de vie des notifications dans la barre

Chaque notification OneSignal affichée sur un appareil est suivie par le SDK. Ce qui se passe ensuite détermine si elle peut réapparaître un jour :
Sur Android, effacez toujours les notifications avec les méthodes du SDK OneSignal plutôt qu’avec les méthodes natives NotificationManager.cancel() ou cancelAll() d’Android. Les notifications annulées avec les API natives ne sont pas marquées comme rejetées, donc le SDK les restaure au prochain redémarrage de l’application.

​
Comportement de clic et de rejet

Cliquer sur une notification ouvre votre application (ou l’URL de lancement de la notification), retire la notification de la barre et déclenche le callback addClickListener() avec la charge utile de la notification et l’ID du bouton d’action cliqué. Si la notification cliquée appartient à un groupe, le SDK met à jour ou supprime le résumé du groupe. Les notifications cliquées ne sont jamais restaurées. Rejeter une notification (la balayer ou appuyer sur Tout effacer dans la barre) la marque comme rejetée et met à jour le compteur de badge ainsi que tout résumé de groupe. Les notifications rejetées ne sont jamais restaurées. Le SDK ne fournit pas de listener de rejet ; le rejet est suivi en interne. Les notifications affichées pendant que votre application est en premier plan passent d’abord par le listener de cycle de vie en premier plan, où vous pouvez empêcher l’affichage.

​
Notifications restaurées (Android)

Android peut retirer de force des notifications sans action de l’utilisateur : lors d’un redémarrage de l’appareil, d’une mise à jour de l’application et d’une fermeture forcée (y compris les gestionnaires de batterie agressifs sur certains appareils). Le SDK Android réaffiche (restaure) automatiquement les notifications concernées au prochain démarrage à froid de l’application, afin que les messages livrés que l’utilisateur n’a jamais vus ni rejetés ne soient pas perdus. Les notifications restaurées réapparaissent silencieusement dans la catégorie Restored de faible importance. Seules les notifications qui n’ont pas été cliquées ni rejetées, qui sont dans leur TTL et qui ont été reçues au cours des 7 derniers jours sont restaurées, jusqu’à 49 notifications. Les règles d’éligibilité complètes et les contrôles se trouvent dans Notifications restaurées (Android). Pour réduire les restaurations, utilisez un ttl plus court lors de l’envoi ou effacez les notifications consommées avec les méthodes du SDK ci-dessous. iOS n’a pas de comportement de restauration.

​
Comportement des badges

Sur iOS, les badges sont définis par la charge utile de la notification (ios_badgeType et ios_badgeCount) et nécessitent un App Group pour que l’extension de service puisse mettre à jour les compteurs avec précision. Par défaut, le SDK efface le badge lorsque l’application s’ouvre. Sur Android, le badge de l’icône de l’application reflète le nombre de notifications OneSignal actives dans la barre et est géré via les catégories de notification. Le SDK met à jour le compteur automatiquement lorsque les notifications sont affichées, rejetées, cliquées ou effacées, et le réinitialise à 0 lorsque vous appelez clearAllNotifications(). La configuration, les options par plateforme et le dépannage sont couverts dans Badges.

​
Effacement des notifications par programmation

Effacez les notifications lorsque leur contenu a été consommé dans votre application, pas lors d’événements du cycle de vie de l’application. Les schémas courants :
  • Synchronisation contenu-consommé : l’utilisateur ouvre l’écran vers lequel pointent les notifications (une boîte de réception, un centre de messages ou un fil d’activité), donc les notifications sont désormais redondantes. Effacez-les toutes, ou utilisez les méthodes ciblées si seule une partie du contenu a été consommée.
  • Déconnexion : effacez tout pour que les notifications de l’utilisateur précédent ne soient pas visibles par l’utilisateur suivant.
Évitez d’effacer à chaque lancement ou passage au premier plan de l’application pour « garder la barre propre ». Les notifications dans la barre stimulent le réengagement, et les effacer supprime ce point d’entrée. Si vous gérez une accumulation de notifications, utilisez collapse_id lors de l’envoi pour remplacer les notifications au lieu de les empiler, ou un TTL plus court pour faire expirer celles qui ne sont pas livrées.

​
clearAllNotifications()

Retire les notifications de votre application de la barre et réinitialise le compteur de badge à 0. Sur Android, cela retire uniquement les notifications créées par OneSignal et les marque comme rejetées afin qu’elles ne soient pas restaurées. Sur iOS, cela retire toutes les notifications livrées de votre application, y compris les notifications locales et les push d’autres fournisseurs. Consultez la référence complète de la méthode.
Si vous effacez au lancement de l’application pour empêcher les notifications restaurées, limitez l’appel à Android dans les applications multiplateformes. Sur iOS, cela retire également les notifications locales et les push d’autres fournisseurs.

​
removeNotification() et removeGroupedNotifications() (Android)

Retirez une seule notification par son ID de notification Android, ou toutes les notifications d’un groupe par sa clé de groupe. Les notifications retirées sont marquées comme rejetées et ne sont pas restaurées. Utilisez ces méthodes lorsque seule une partie du contenu de la barre a été consommée, comme une conversation parmi plusieurs. Consultez la référence de la méthode.

​
Rejeter automatiquement les notifications après un délai

Il n’existe pas de paramètre à l’envoi qui retire une notification affichée après un temps donné. Ce qui est possible diffère selon la plateforme :
  • Android 8.0 (API 26) et versions ultérieures : définissez un délai d’expiration dans une extension de service de notification en utilisant setTimeoutAfter(). Android retire la notification du volet lorsque le délai expire. Sur les appareils sous API 26, l’appel est ignoré et la notification reste jusqu’à ce que l’utilisateur interagisse avec elle.
  • iOS : non pris en charge. iOS n’a aucun moyen de faire expirer automatiquement une notification livrée. Les options les plus proches sont de la remplacer par une notification plus récente via collapse_id, ou de la retirer depuis une Notification Service Extension avec la méthode d’Apple removeDeliveredNotifications(withIdentifiers:) lorsqu’un push ultérieur arrive.
Pour rendre le délai propre à chaque message plutôt que fixé dans le code, envoyez la durée dans additionalData et lisez-la depuis l’événement dans votre extension de service.
Une notification retirée par setTimeoutAfter() est rejetée par le système, donc le SDK OneSignal ne la restaure pas. Ne confondez pas cela avec ttl, qui contrôle combien de temps un message non livré attend un appareil hors ligne et ne retire jamais une notification affichée.

​
Personnalisation des notifications avec les extensions de service

Les extensions de service s’exécutent avant l’affichage d’une notification, vous permettant de modifier son apparence, de recevoir des données en arrière-plan ou d’empêcher entièrement l’affichage :
  • Sur Android, implémentez INotificationServiceExtension et utilisez setExtender() pour modifier les options NotificationCompat, ou appelez event.preventDefault() pour supprimer l’affichage.
  • Sur iOS, utilisez une UNNotificationServiceExtension (la OneSignalNotificationServiceExtension créée lors de la configuration) pour les médias enrichis, les incréments de badge et la livraison confirmée.
Sur Android, votre extension de service s’exécute également pour les notifications restaurées. Les effets de bord dans onNotificationReceived (appels d’analyse, requêtes API, écritures en base de données) se réexécutent lorsque les notifications sont restaurées, et les modifications de l’extender comme setChannelId() s’appliquent aussi aux restaurations, ce qui peut les faire alerter bruyamment. Concevez votre extension pour que les options d’alerte ne s’appliquent qu’aux notifications fraîchement livrées.

​
FAQ

​
Pourquoi d’anciennes notifications réapparaissent-elles à l’ouverture de l’application sur Android ?

Le SDK Android restaure les notifications qui ont été retirées de force de la barre, par exemple après un redémarrage de l’appareil, une mise à jour de l’application ou une fermeture forcée. Les notifications que l’utilisateur a rejetées ou cliquées ne sont pas restaurées. Consultez Notifications restaurées (Android) pour les règles d’éligibilité et les contrôles.

​
Le TTL retire-t-il une notification de la barre après son expiration ?

Non. Le TTL contrôle combien de temps un message non livré attend un appareil hors ligne, et sur Android il délimite également quelles notifications peuvent être restaurées. Il ne retire jamais une notification déjà affichée dans la barre. Pour retirer les notifications affichées, utilisez les méthodes d’effacement. Pour les retirer après un temps donné sur Android, consultez Rejeter automatiquement les notifications après un délai.

​
Puis-je effacer le badge sans effacer la barre ?

Oui sur iOS : le badge s’efface automatiquement lorsque l’application s’ouvre (sauf si désactivé), laissant le contenu de la barre en place. Sur Android, le badge reflète les notifications actives dans la barre, il ne peut donc pas être défini indépendamment d’elles. Consultez Badges.

​
Existe-t-il un listener pour le rejet d’une notification par l’utilisateur ?

Non. Le SDK suit le rejet en interne pour éviter de restaurer les notifications rejetées, mais n’expose pas d’événement de rejet. Le listener de clic couvre uniquement les clics.

Référence du SDK mobile

Référence complète des méthodes et listeners de notification.

Charge utile OSNotification

Champs de la charge utile et règles des notifications restaurées.

Extensions de service mobiles

Interceptez et personnalisez les notifications avant l’affichage.