Как отправить push сообщение android

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-уведомлений Pushover для Android и iOS в связке с PHP

Пример задачи

Предположим, что раз в день мы хотим знать что-либо о количестве заказов на сайте за день и их стоимости.
Сайт крутится на некоторой CMS на PHP и mySQL, принимающая сторона имеет стильные iPhone и Android-телефоны.
Срочность доставки сообщения не относится к жизненно-важным показателям.
Надо найти условно безгеморройное решение.

Pushover

Pushover — это скромный сервис уведомлений, а также приложения для iOS и Android, планируются поделки и для BlackBerry и OS X Mountain Lion. Сервис имеет свой API, позволяет отправлять бесплатно до 7.5 тысяч сообщений в месяц.


Сообщение, помимо основного текста сообщения длиной 512 символов, может содержать крупный заголовок, URL (тогда длина сообщения увеличивается до 500) и его тайтл (все отображается отдельными сформированными блоками, потому такое разграничение). Сообщение можно доставить под неким выбранным указанным приоритетом. Пользователь может указать «тихие» часы, когда его не стоить будить уведомления, а также подключать и отключать устройства, на которые будут приходить уведомления.
Уведомление может быть доставлено пользователям, предоставившим свой код, всем устройствам этого пользователя или по выбору. Для приема сообщения пользователю необходимо быть зарегистрированным в сервисе и обладать хотя бы одним рабочим устройством.

Читайте также:  Сенсорный геймпад для андроид
Добавление пользователя


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

Добавление сервиса

Добавление сервиса ничуть не сложнее. Из личного кабинета надо перейти на страницу создания приложения, где предлагается описать продукт:

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

Связывание приложений и получателей

… не выполняется никак. Любое приложение может отправить любому пользователю уведомление, если знает его токен. Прием токенов от населения остается на совести приложения. Также как и отписка от рассылок.

Небольшое, емкое и понятное. Для отправки сообщения в POST-запросе к api.pushover.net/1/messages.json или api.pushover.net/1/messages.xml минимально необходимо указать:

  • token — хэш-токен вашего приложения или сервиса.
  • user — хэш-токен пользователя, которому вы отправляете уведомление.
  • message — текстовая часть сообщения.

Дополнительно к этому можно добавить:

  • device — идентификатор устройства пользователя, дабы не отсылать уведомления сразу на все его устройства
  • title — заголовок сообщения, если не указан, будет показано название сервиса
  • url — ссылка на web-страницу, если в этом есть необходимость
  • url_title — заголовок к ссылке
  • priority — приоритет сообщения, ставится в 1 для высокого приоритета, обходящего все «тихие» часы и -1 для тихого уведомления.
  • timestamp — UNIX метка времени, когда это уведомлениебыло создано. Расписания доставки сообщений сервисом не предусмотрено.
Ответ сервера

Ответ сервера будет представлен в json или xml формате (в зависимости от расширения вызываемого скрипта).
Если все прошло удачно будет отдан объект содержанием поля status, равном 1.
Иначе, поле status будет содержать нечто иное, а поле errors — массив описания ошибок. Вот примеры ответов удачной и неудачной отправок в формате XML:
и

На главной странице и в факе в разделах «смотрите, как легко!» приводятся коды простейшего скрипта на различных языках для отправки и есть ссылка на 3rd-party php-класс от Chris Schalenborgh.
Везде используется сURL, что впрочем, понятно.

Зафигарим свой класс

Минимальное сообщение теперь довольно просто отправить, ошибки можно разбирать:

Источник

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 использовать одно и тоже значение. Затем убить второй сервис. При этом уведомление пропадет из статус бара, но функциональные и приоритетные возможности первого сервиса останутся.

Читайте также:  Как изменить пароль аккаунта google android

Реализовав данный подход, мы отправили сборку на тест. По результатам выяснилось, что система все-таки выгружает сервис, а по логам мы видели, как происходили существенные временные разрывы при запросе данных в фоне с нашего сервера. Поэтому приступили к реализации второго варианта — 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 уведомлений (таким образом исключается ситуация банального разрыва соединения, таймаута и пр.);
  • необходимо прогонять данный алгоритм периодически (например, раз в неделю, или после обновления ОС на устройстве).

Всем добра. И поменьше подобных костылей.

Источник

Оцените статью