Push уведомления в Android с помощью Firebase Cloud Messaging для начинающих
. GCM users are strongly recommended to upgrade to FCM, in order to benefit from new FCM features today and in the future.
В этой статье мы разберем тестовый проект и рассмотрим один подводный камень связанный с иконкой уведомления.
- Android Studio
- Код демо-проекта с github
- 20 минут свободного времени
Шаг 1.
Скачайте демо-проект и откройте его в своей любимой Android Studio.
Теперь нам нужно пойти в Firebase console и добавить наш проект.
Затем нажимаем «Добавьте Firebase в свое приложение для Android».
Название пакета, если вы все делаете по манула: «com.google.firebase.quickstart.fcm».
На втором шаге скачиваем файл google-service.json и добавляем его к проекту.
Нажимаем готово, зависимости уже добавлены в тестовом проекте.
Подготовительная часть закончена, можно нажимать кнопку «Запустить приложение»
В процессе компиляции вы можете получить 2 ошибки:
Missing api_key/current key with Google Services 3.0.0
В этом случае вам нужно зайти в настройки проекта и перезакачать файл google-service.json. Это странный баг, но благо легко лечится.
Вторая ошибка — это:
Failed to resolve: com.google.firebase:firebase-core:9.0.0
Тогда вам нужно обновить Google Play Service и Google Repository. Ссылка на Stackoverflow.
После запуска приложения, в Android monitor увидите наш токен. Можно отправляться тестировать. Идем в консоль, ищем наше приложение, и идем в раздел Grow->Notifications:
Нажимаем создать сообщение:
Вводим наши данные, нажимаем отправить и наблюдаем в Android monitor как все пришло.
Теперь к самому интересному
Самый частый вопрос: как поменять иконку уведомления, когда приложение работает в бэкграунде?
Дело в том, что когда приложение находится в бэкграунде, то оно отправляется сразу в Notification center, и функция
Чтобы использовать свои иконки уведомлений, вам нужно посылать сообщение через API, через консоль такая кастомизация на данный момент не работает.
UPD: Если вы хотите, чтобы все ваши сообщения даже когда приложение в background или убито, обрабатывались с помощью
в приложении, то отправляйте data-сообщения, т.е. без секции notification
Ссылка на API. Для тестов можно использовать старый-добрый CURL.
Вот в целом и все, что вам нужно знать чтобы попробовать новые push уведомления.
Источник
Push уведомления в Android. Грабли, костыли и велосипеды
На написание данной статьи меня подтолкнула задача, которая была поставлена передо мной в одном из рабочих проектов: реализовать Push-уведомления в приложении. Казалось, все просто: штудируешь документацию, примеры и вперед. К тому же, опыт работы с уведомлениями уже был. Но не тут то было…
Сервис, в рамках которого реализовано приложение под Android, предъявляет довольно жесткие требования к работе Push-уведомлений. Необходимо в пределах 30-60 секунд оповестить пользователя о некотором действии. При успешном оповещении с устройства пользователя отправляется запрос на сервер с соответствующим статусом. Из документации известно, что сервис GCM (Google Cloud Messaging) не гарантирует доставку PUSH-уведомлений на устройства, поэтому в качестве backdoor варианта, при нарушении этих временных рамок, наш сервис уведомляет пользователя с помощью SMS сообщения. Поскольку стоимость SMS сообщения существенно выше чем PUSH-уведомления, необходимо максимально сократить поток SMS сообщений на клиентские устройства.
Проштудировав документацию и прикрутив пуш-уведомления, мы разослали нескольким клиентам первую сборку приложения для теста и стали ждать. Результаты были примерно следующими:
- при активном Wifi соединении все работает идеально: уведомления доставляются, клиенты рады.
- при активном мобильном интернете началось самое веселье.
Некоторые клиенты писали, что испытывают задержки в доставке пушей, либо получали одновременно и PUSH и SMS, что достаточно не практично. Другие писали, что вовсе не получали уведомлений, а только SMS. У третьих, как и у нас на тестовых устройствах, все было ок. Собрав с недовольных клиентов максимально возможную информацию, стали разбираться в проблеме и вывели следующий список ограничений (этот список позже вылился в полноценный FAQ):
- включенный режим Энергосбережения (например, Stamina на устройствах Sony) влияет на работу Push уведомлений;
- у пользователя обязательно должен быть минимум 1 активный Google аккаунт на устройстве;
- необходимо удостовериться в том, что на устройстве установлена актуальная версия приложения “Сервисы Google Play”;
- проверить, не отключены ли уведомления для приложения (галочка на страничке приложения в настройках телефона);
- проверить, не ограничена ли работа фонового режима для приложения (настройка расположена в меню «Использование данных»);
- в документации к GCM указано, что уведомления рассылаются только по определенным портам, поэтому настройки роутера, файервола и антивируса так же стоит учитывать.
Разослав данную памятку по всем клиентам, мы снова стали ждать результатов. И они оказались снова «не очень». Стали копать дальше.
На данном этапе очень сильно помогла статья, написанная ребятами из Mail.ru. В ней очень подробно описаны тонкости реализации GCM на клиентской стороне, а так же моменты, в связи с которыми отказываются работать Push уведомления в мобильных сетях. В конечном счете было принято решение о том, чтобы держать свое соединение с сервером в связке с GCM.
Перед тем, как приступить к решению, стоить выделить несколько очень важных моментов, которые позволяют сузить круг потенциально «нерабочих» устройств:
- проблема возникает только при подключении к мобильному интернету;
- по данным клиентов, проблема возникает на версии андроида 4 и выше.
И так, перейдем к реализации.
Бывалый разработчик под Android сходу скажет, что решений задачи как минимум 2: использовать Service или AlarmManager. Мы попробовали оба варианта. Рассмотрим первый из них.
Для того, чтобы создать неубиваемый системой сервис, который постоянно будет висеть в фоне и выполнять нашу задачу, мы использовали метод:
- notificationId — некоторый уникальный идентификатор уведомления, который будет выведен в статус баре и в выезжающей шторке;
- notification — само уведомление.
В данном случае обязательным условием является отображение уведомления в статус баре. Такой подход гарантирует то, что сервису будет дан больший приоритет (поскольку он взаимодействует с UI частью системы) в момент нехватки памяти на устройстве и система будет выгружать его одним из последних. Нам это уведомление не нужно, поэтому мы воспользовались следующим велосипедом: достаточно запустить одновременно с первым сервисом второй и для обоих сервисов в качестве notificationID использовать одно и тоже значение. Затем убить второй сервис. При этом уведомление пропадет из статус бара, но функциональные и приоритетные возможности первого сервиса останутся.
Реализовав данный подход, мы отправили сборку на тест. По результатам выяснилось, что система все-таки выгружает сервис, а по логам мы видели, как происходили существенные временные разрывы при запросе данных в фоне с нашего сервера. Поэтому приступили к реализации второго варианта — AlarmManager.
AlarmManager — это класс, который предоставляет работу с, грубо говоря, «будильником». Он позволяет указать время, по достижении которого система отправит широковещательное уведомление, которое позволит пробудить наше приложение и даст ему возможность выполнить необходимые действия. В работе этого метода есть некоторые ограничения, и их необходимо обработать:
- данные о «будильниках» будут стерты после перезагрузки устройства;
- данные о «будильниках» будут стерты после обновления приложения.
Первыми граблями, на которые мы наступили, был метод
который позволяет установить повторяющийся с некоторым интервалом «будильник». Прикрутив данный способ, стали тестировать, и тесты показали обратное — «будильник» не повторялся. Стали разбираться в чем дело, посмотрели документацию. И именно там нашли ответ на вопрос — начиная с 19 API lvl (Kitkat) абсолютно все «будильники» в системе стали разовыми. Вывод — всегда читайте документацию.
Эти грабли не были поводом для расстройства, ведь решение задачи довольно простое — запускать единоразовый «будильник» и после срабатывания переустанавливать его. При реализации этого подхода мы наткнулись на следующие грабли — оказалось, что для разных уровней API необходимо по разному устанавливать будильники, при этом в документации ничего сказано не было. Но данная проблема решилась достаточно просто — методом «тыка» и «гугления». Ниже представлен пример кода, позволяющий правильно устанавливать «будильники»:
Хочу обратить внимание на флаг AlarmManager.RTC_WAKEUP — именно с помощью него система позволит нашему приложению «проснуться» при неактивном экране, когда устройство находится в заблокированном состоянии.
Данный подход с «будильникам» дал нам нужный результат — приложение в фоне корректно опрашивает сервер на наличие новых данных. Сейчас мы дорабатываем алгоритм. На данный момент реализуем и тестируем следующую оптимизацию, которая позволит сузить круг устройств и тем самым уменьшить нагрузку на сервер:
- в сообщении, отправленном средствами GCM на устройство, содержится некоторый уникальный ID;
- получив данные GET запросом в фоновом режиме проверяем, существуют ли уже запись с таким ID на устройстве;
- если локально на устройстве таких данных нет, мы запоминаем этот ID и время его получения T1;
- ждем PUSH с таким же ID, при получении запоминаем время T2 и проверяем разницу между T2 и T1;
- если разница составляет больше некоторого временного критерия (значения), то на устройстве наблюдается проблема с доставкой уведомлений и для корректной работы сервиса необходимо постоянно запрашивать данные в фоновом режиме с сервера (критерий советую выбирать исходя из решаемой задачи. В нашем случае, был выбран критерий равный 5 минутам);
- данную разницу стоит вычислять несколько раз, например 5-10 раз, только после этого делать вывод о том, что устройство действительно содержит проблему с получением Push уведомлений (таким образом исключается ситуация банального разрыва соединения, таймаута и пр.);
- необходимо прогонять данный алгоритм периодически (например, раз в неделю, или после обновления ОС на устройстве).
Всем добра. И поменьше подобных костылей.
Источник
OneSignal Push Notification Service Documentation
OneSignal Help & Documentation
Welcome to the OneSignal New IA developer hub. You’ll find comprehensive guides and documentation to help you start working with OneSignal New IA as quickly as possible, as well as support if you get stuck. Let’s jump right in!
Data & Background Notifications
How to send data/background/silent notifications. VoIP notifications using OneSignal. Works with iOS, Android and derivatives like Amazon.
Background/Data notifications are «silent» meaning they do not display any message or play a sound when received by your app. They are designed to keep your app’s data «up-to-date» by providing a way to «wake up» the app to refresh the data in the background.
Background/Data Notification Limitations
If you force close the app, it cannot receive background/data notifications.
iOS Apps are force closed when you swipe them away.
Android Apps can be force quit in the settings, but some device manufacturers force quit the app automatically when swiping them away. More details.
Limited Support for Non-Native SDKs
If you are using a non-native SDK like Unity, React Native, Cordova, or Flutter, you must use native Java/Kotlin or Swift/Objective-C to implement Data Push Notifications.
iOS will need to implement a special delegate. You can learn more at the bottom of Handling Remote Notifications.
For Android, you will need to implement the NotificationExtenderService.
Before getting started, we highly recommend getting familiar with Apple’s Pushing Background Updates to Your App and Apple’s Guide on Creating Notification Payloads.
Setting up and sending background notifications in iOS requires 3 components:
You must have the Notification Service Extension setup in your app. See Step 1 of our iOS Native SDK setup guide to add one to your Xcode project if you have not done so already.
You must not send a message (no contents ) and you must send content_available to wake the app if it is running in the background.
Native iOS Apps: Process the data within the Notification Received Handler while the app is running in the foreground or background.
Non-Native iOS Apps: Process data within the Native iOS API within the AppDelegate application(_:didReceiveRemoteNotification:fetchCompletionHandler:) method.
iOS Force Quit Limitations
Apple does not allow the processing of background data if the App has been swiped away.
If the app has been swiped away, you will need to add contents (a message) to the push (cannot be a background message) and handle the data within the UNNotificationServiceExtension.didReceive method.
There is no way to process a background notification when the app has been force quit.
The OneSignal SDK is set up to only send data notifications to subscribed devices. If you want to target unsubscribed devices with data notifications, you will need to follow this workaround.
Data notifications are handled within the NotificationExtenderService — This can be set up to receive data notifications when your app is not running, or to override how notifications are shown in the notification shade.
OneSignal will automatically send the notification as a data notification under the following notification parameter conditions:
- content_available : true
- alert is omitted
- badge is omitted
- sound is omitted
- category is omitted
- thread_id is omitted
- subtitle is omitted
- contents is omitted
- headings is omitted
OneSignal supports VoIP notifications for iOS. Our SDKs do not support registration for a VoIP token at this time.
On iOS, unfortunately this is not possible right now.
While we use the NotificationServiceExtension to send the confirmed delivery, iOS will not trigger the NSE if you do not add a message to the body of the push. It is also not possible to work around this by setting a body then making it nil or blank in the NSE. If you try to do that iOS puts back the body and displays it. You can’t prevent a notification from showing with the NSE either.
Источник
