Options de pont pour les notifications

Par défaut, le système ponte, ou partage, les notifications d'une application de téléphone vers toutes les montres associées. Si vous créez une application pour les montres connectées et que celle-ci existe également sur un téléphone associé, les utilisateurs peuvent recevoir des notifications en double, l'une générée et pontée par l'application pour téléphone et l'autre générée par l'application de la montre. Wear OS inclut des fonctionnalités permettant de contrôler quand et comment ponter les notifications.

Éviter les notifications en double

Lorsque vous créez des notifications à partir d'une source externe, comme Firebase Cloud Messaging, votre application pour téléphone et votre application pour montre peuvent chacune afficher leurs propres notifications sur la montre. Pour éviter les doublons, désactivez le pontage par programmation dans votre application pour montre.

Utiliser des balises de pont

Pour associer certaines notifications créées par votre application pour téléphone à la montre lorsque votre application pour montre est installée, définissez des balises de pont.

Définissez une balise de pont sur une notification à l'aide de la setBridgeTag(String) méthode, comme illustré dans l'exemple de code suivant :

val notification = NotificationCompat.Builder(context, channelId)
    // ... set other fields ...
    .extend(
        NotificationCompat.WearableExtender()
            .setBridgeTag("tagOne")
    )
    .build()
BridgingConfiguration.kt

Désactiver le pontage

Vous pouvez désactiver le pontage pour toutes les notifications ou seulement pour certaines d'entre elles. Nous vous recommandons de désactiver le pontage de manière sélective.

Désactiver le pontage pour certaines notifications uniquement

Vous pouvez désactiver le pontage de manière dynamique et, si vous le souhaitez, autoriser certaines notifications en fonction de leur balise. Par exemple, pour désactiver le pontage pour toutes les notifications, à l'exception de celles balisées comme tagOne, tagTwo ou tagThree, utilisez l' BridgingConfig objet, comme illustré dans l'exemple suivant :

// In this example, bridging is only enabled for tagOne, tagTwo and tagThree.
BridgingManager.fromContext(context).setConfig(
    BridgingConfig.Builder(context, isBridgingEnabled = false)
        .addExcludedTags(listOf("tagOne", "tagTwo", "tagThree"))
        .build()
)
BridgingConfiguration.kt

Désactiver le pontage pour toutes les notifications (non recommandé)

Pour éviter le pontage de toutes les notifications provenant d'une application pour téléphone, utilisez l' <meta-data> entrée dans le fichier manifeste de l'application pour montre, comme illustré dans l' exemple suivant :

<!-- Beware, this can have unintended consequences before the user is signed-in -->
<meta-data
    android:name="com.google.android.wearable.notificationBridgeMode"
    android:value="NO_BRIDGING" />
AndroidManifest.xml

Définir un ID de refus pour synchroniser les notifications similaires

Lorsque vous empêchez le pontage avec la fonctionnalité correspondante, les notifications ignorées ne sont pas synchronisées sur les appareils de l'utilisateur.

Toutefois, si des notifications similaires sont créées à la fois sur le téléphone et sur la montre, vous souhaitez que les deux notifications soient ignorées lorsque l'utilisateur en ignore une.

Dans le NotificationCompat.WearableExtender, vous pouvez définir un ID unique global de sorte que, lorsqu'un utilisateur ignore une notification, les autres notifications portant le même ID sur des montres associées le soient également.

La classe NotificationCompat.WearableExtender comporte des méthodes qui vous permettent d'utiliser des ID de refus, comme illustré dans l'exemple suivant :

Lorsque l'utilisateur ignore la notification, toutes les autres notifications ayant le même ID de refus sont ignorées sur la montre et sur le téléphone. Pour récupérer un ID de refus, utilisez getDismissalId().

Dans l'exemple suivant, un ID unique global est spécifié pour une nouvelle notification de sorte que les refus soient synchronisés :

val notification = NotificationCompat.Builder(context, channelId)
    // ... set other fields ...
    .extend(
        NotificationCompat.WearableExtender()
            .setDismissalId("abc123")
    )
    .build()
BridgingConfiguration.kt

Notifications locales uniquement

Pour éviter les notifications en double, vous pouvez également utiliser setLocalOnly() pour rendre les notifications locales au téléphone.

Toutefois, n'utilisez cette méthode que si la notification doit apparaître uniquement sur l'appareil qui l'a créée. Cela inclut non seulement les appareils Wear OS, mais également d'autres accessoires connectés et tout autre appareil connecté. Une notification locale uniquement n'est pas pontée, même si votre application n'est pas installée sur la montre.

Lorsque vous créez une application Wear OS et une application pour téléphone qui créent toutes deux des notifications, n'utilisez pas cette approche pour éviter les notifications en double. Utilisez plutôt les options de pontage.

Par exemple, utilisez une notification locale uniquement lorsqu'un utilisateur télécharge un fichier sur un téléphone et que la notification indique que le téléchargement est terminé.

Cas où les notifications ne sont pas pontées

Le système ne ponte pas les types de notifications suivants :

Considérations d'implémentation pour les notifications pontées

Le transfert ou la suppression des notifications pontées sur un accessoire connecté peut prendre du temps. Lorsque vous concevez vos notifications, veillez à éviter tout comportement inattendu causé par cette latence. Les consignes suivantes contribuent à s'assurer que les notifications pontées fonctionnent avec les notifications asynchrones :

  • Si vous annulez une notification sur le téléphone, l'annulation de la notification correspondante sur la montre peut prendre un certain temps. Pendant ce temps, l'utilisateur pourrait envoyer l'un des intents en attente au niveau de cette notification. C'est pourquoi votre application doit recevoir les intents en attente à partir des notifications qu'elle a annulées : lorsque vous annulez des notifications, assurez-vous que les destinataires d'intent en attente de ces notifications sont valides.
  • N'annulez pas et ne redéclenchez pas l'ensemble de vos notifications en même temps. Ne modifiez ou ne supprimez que les notifications qui ont été réellement modifiées. Cette approche évite la latence liée à la mise à jour de l'accessoire connecté et réduit l'impact de votre application sur l'autonomie de la batterie.

Considérations de conception

Les notifications Wear OS sont soumises à des consignes de conception spécifiques. Pour en savoir plus, consultez les consignes de conception Wear OS.