Эта страница переведена с помощью Cloud Translation API.

Параметры моста для уведомлений

По умолчанию система передает , или обменивается, уведомлениями из мобильного приложения со всеми сопряженными часами. Если вы разрабатываете приложение для часов, и это приложение также установлено на сопряженном телефоне, пользователи могут получать дублирующие уведомления — одно, которое генерирует и передает мобильное приложение, и другое, которое генерирует мобильное приложение. Wear OS включает в себя функции для управления тем, как и когда передаются уведомления.

Избегайте дублирования уведомлений.

При создании уведомлений из внешнего источника, например, из Firebase Cloud Messaging , ваше мобильное приложение и приложение для часов могут отображать на часах собственные уведомления. Во избежание дублирования отключите функцию объединения уведомлений программно в приложении для часов.

Используйте теги моста

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

Установите тег-мост для уведомления, используя метод setBridgeTag(String) , как показано в следующем примере кода:

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

Отключить мостовое соединение

Вы можете отключить функцию "мост" для некоторых или для всех уведомлений. Мы рекомендуем отключать функцию "мост" выборочно.

Отключить мостовое соединение только для некоторых уведомлений

Вы можете динамически отключать мостовое соединение и, при необходимости, разрешать прохождение некоторых уведомлений в зависимости от их тега. Например, чтобы отключить мостовое соединение для всех уведомлений, кроме тех, которые помечены тегами tagOne , tagTwo или tagThree , используйте объект BridgingConfig как показано в следующем примере:

// 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

Отключите мостовое соединение для всех уведомлений (не рекомендуется).

Чтобы предотвратить перенаправление всех уведомлений из мобильного приложения, используйте запись <meta-data> в файле манифеста приложения для часов, как показано в следующем примере:

<!-- 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

Укажите идентификатор закрытия уведомления, чтобы синхронизировать похожие уведомления.

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

Однако, если аналогичные уведомления создаются как на телефоне, так и на часах, вам нужно, чтобы оба уведомления закрывались, когда пользователь закрывает одно из них.

В классе NotificationCompat.WearableExtender можно установить глобальный уникальный идентификатор, чтобы при закрытии пользователем уведомления закрывались и другие уведомления с тем же идентификатором на сопряженных часах.

Класс NotificationCompat.WearableExtender имеет методы, позволяющие использовать идентификаторы закрытия, как показано в следующем примере:

Когда пользователь закрывает уведомление, все остальные уведомления с тем же идентификатором закрытия закрываются как на часах, так и на телефоне. Чтобы получить идентификатор закрытия, используйте getDismissalId() .

В следующем примере для нового уведомления указан глобально уникальный идентификатор, поэтому уведомления об отклонении синхронизируются:

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

Уведомления только для локального доступа

Чтобы предотвратить дублирование уведомлений, вы также можете использовать setLocalOnly() чтобы сделать уведомления локальными для телефона.

Однако используйте этот метод только в том случае, если уведомление должно отображаться только на устройстве, которое его создало. Это включает не только устройства Wear OS, но и другие носимые устройства и любые другие подключенные устройства. Уведомление, отображаемое только локально, не будет работать, даже если ваше приложение не установлено на часах.

При разработке приложений для Wear OS и телефона, которые одновременно генерируют уведомления, не используйте этот подход для предотвращения дублирования уведомлений. Вместо этого используйте варианты мостового соединения.

Например, можно использовать локальное уведомление, когда пользователь загружает файл на телефон и уведомление указывает на завершение загрузки.

Когда уведомления не передаются между узлами

Система не поддерживает следующие типы уведомлений:

Локальные уведомления устанавливаются с помощью Notification.Builder.setLocalOnly(boolean) .
Текущие уведомления устанавливаются с помощью Notification.Builder.setOngoing(boolean) или Notification.FLAG_ONGOING_EVENT .
Неотменяемые уведомления устанавливаются с помощью Notification.FLAG_NO_CLEAR .
Уведомления, в которых в соответствующем приложении для носимых устройств отключена функция объединения уведомлений .

Вопросы реализации системы мостовых уведомлений

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

Если вы отмените уведомление на телефоне, может потребоваться некоторое время для отмены соответствующего уведомления на часах. В течение этого времени пользователь может отправить один из ожидающих интентов этого уведомления. По этой причине продолжайте получать ожидающие интенты в вашем приложении от отмененных уведомлений: при отмене уведомлений сохраняйте действительными получатели ожидающих интентов этих уведомлений.
Не отменяйте и не запускайте сразу весь набор уведомлений. Изменяйте или удаляйте только те уведомления, которые действительно были изменены. Это позволит избежать задержек при обновлении носимого устройства и снизит влияние вашего приложения на время работы от батареи.

Вопросы проектирования

Для уведомлений Wear OS существуют собственные рекомендации по дизайну. Дополнительную информацию можно найти в разделе « Рекомендации по дизайну Wear OS» .