Как установить высокий приоритет для уведомления pu sh, которое отправляется в NotificationHub - PullRequest
5 голосов
/ 28 мая 2020

Я успешно реализовал функцию Azure, которая отправляет уведомления pu sh в NotificationHub для Android, iOS и UWP. Во время тестирования я обнаружил, что когда Android устройство находится в режиме дремоты, уведомление sh не доставляется на экран блокировки. Доставляется только при разблокировке телефона.

Я обнаружил это сообщение о переполнении стека , которое помогло мне исправить его с помощью метода SendFcmNativeNotificationAsyn c. Я использовал этот код:

string payload = @"{
                    ""data"":{
                        ""notificationtype"":""sap"",
                        ""title"":""value2"",
                    },
                        ""priority"":""high""
                    }";

await hub.SendFcmNativeNotificationAsync(payload);

Однако моя реализация с использованием метода SendNotificationAsyn c, который работает для всех 3 платформ, но не в режиме Doze. Это мой код для отправки уведомления:

Dictionary<string, string> templateParameters = new Dictionary<string, string>();

templateParameters["alert"] = "Test";
templateParameters["title"] = "Whosap";

var notification = new TemplateNotification(templateParameters);
await hub.SendNotificationAsync(notification);

Я пытался установить заголовок уведомления:

var headers = new Dictionary<string, string> { { "android", @"{""priority"": ""high""}" } };
notification.Headers = headers;

Но это не сработало. Кто-нибудь знает, как установить приоритет в объекте TemplateNotification и отправить его с помощью метода SendNotificationAsyn c?

Вот как я заставляю / отменяю режим ожидания устройства:

adb shell dumpsys deviceidle force-idle
adb shell dumpsys deviceidle unforce

1 Ответ

1 голос
/ 01 июня 2020

Исходя из вашего комментария, что вы хотите иметь «только информативные уведомления pu sh», к сожалению, вы не можете заставить телефон показывать ваши уведомления каждый раз. Это не является ограничением ни для Xamarin, ни даже для Azure функций в этом вопросе. Даже некоторые собственные приложения Google ведут себя одинаково.

Глядя на Контрольный список доз :

Если ваши пользователи должны сразу увидеть уведомление, обязательно используйте an Сообщение с высоким приоритетом FCM

Даже если мы посмотрим на Использование FCM для взаимодействия с вашим приложением во время простоя устройства :

FCM оптимизирован для работы с режимами ожидания Doze и App Standby с помощью высокоприоритетных сообщений FCM . Сообщения с высоким приоритетом FCM позволяют надежно разбудить приложение для доступа к сети, даже если устройство пользователя находится в режиме ожидания или приложение находится в режиме ожидания приложения. В режиме ожидания или в режиме ожидания система доставляет сообщение и предоставляет приложению временный доступ к сетевым службам и частичной блокировке пробуждения, а затем возвращает устройство или приложение в состояние ожидания.

Пока все выглядит вот так, если вы решите использовать сообщения с высоким приоритетом , все должно работать нормально. Однако это еще не все. Вы правильно установили высокий приоритет "priority":"high". К сожалению, для этого параметра есть некоторые предостережения ( из документации ):

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

Это означает, что если вы отправляете только информативное уведомление, этого будет недостаточно, чтобы вывести устройство из режима Doze и показать уведомление. Проверки / ограничения стали еще жестче с Android P. Читайте о резервных сегментах приложений здесь .

Хорошо то, что выход из режима Doze происходит в форме различных событий / взаимодействий:

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

По крайней мере, на телефонах, которые я пробовал, в обычном повседневном сценарии уведомления отключаются либо во время вашего ночного сна, либо когда устройство сидит без каких-либо взаимодействий / движений и т. Д. c.

Однако, если вам действительно нужно доставлять каждое уведомление, а это критически для UX, тогда у вас есть 2 варианта:

  1. Если вы хотите, чтобы пользователь не вмешивался - установите высокий приоритет и просто надейтесь, что система время от времени будет показывать некоторые уведомления (возможно, во время окна обслуживания). Не лучший способ, но по умолчанию он может работать время от времени.
  2. Если вы хотите гарантировать, что уведомления будут появляться во всплывающих окнах, создайте экран с описанием проблемы для пользователя, а затем перейдите к пользователю на Settings -> Apps & notifications --> Advanced --> Special app access --> Battery optimisation. Затем он / она может выбрать ваше приложение и вручную установить для него Не оптимизировать . Имейте в виду, что это не считается лучшей практикой и: а) пользователь не должен знать о последствиях этого действия и б) лучше оставить все ОС, чтобы она работала должным образом.

Подводя итог, вам не нужно устанавливать приоритет вашего уведомления на высокий , потому что ОС увидит, что это простое информативное уведомление, и теперь разбудит телефон. Имейте в виду, что когда телефон переходит в режим «глубокого сна», он не должен и не должен просыпаться для информативных уведомлений, так что нет смысла пытаться - это задумано. В противном случае любой другой разработчик может установить высокий приоритет уведомлений, и телефон никогда не сможет go перейти в режим дремоты, что сделает эту функцию бесполезной.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...