Android get firebase push token

Firebase (FCM) как получить токен

Я впервые использую FCM.

Я загружаю образец из firebase / quickstart-android и устанавливаю FCM Quickstart. Но я не могу получить токен из журнала, даже нажав кнопку LOG TOKEN в приложении.

Затем я пытаюсь отправить сообщение с помощью консоли Firebase и настраиваю таргетинг на имя моего пакета приложения. Я получаю входящие сообщения.

Я хочу знать, можно ли использовать FCM? GCM все в порядке.

Потому что я не разработчик Android, а просто backend-разработчик. Так что мне нужно время, чтобы решить эту проблему. На мой взгляд, в тестовом приложении есть несколько ошибок.

Добавьте это в MainActivity.java.

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

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

И тогда почему я не могу получить уведомление. FirebaseMessagingService.onMessageReceived не вызывает sendNotification

САМЫЙ БЫСТРЫЙ И ХОРОШИЙ ДЛЯ ПРОТОТИПА

Быстрое решение — сохранить его в sharedPrefs и добавить эту логику в onCreate метод в вашем MainActivity или классе, расширяющем Application.

ЧИСТЫЙ ПУТЬ

Лучше создать сервис и придерживаться аналогичной логики. Сначала создайте новую службу

А затем добавьте его в файл AndroidManifest

Наконец, вы можете использовать статический метод из своей службы MyFirebaseMessagingService.getToken(Context);

САМЫЕ БЫСТРЫЕ, НО УСТАРЕВШИЕ

Он все еще работает, когда вы используете более старую библиотеку firebase, чем версия 17.xx

Команда Firebase Android SDK немного изменила API. Я реализовал логику «Token to Server» следующим образом:

В моем экземпляре FirebaseMessagingService:

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

1. Когда новый пользователь входит в систему, вам необходимо привязать токен к новому пользователю (отправить его на сервер). Поскольку токен может быть обновлен во время сеанса старого пользователя, а сервер не знает токен нового пользователя.
2. Когда пользователь выходит из системы, вам нужно отвязать токен. Потому что пользователь больше не должен получать уведомления / сообщения.

Используя новый API, вы можете получить такой токен:

Удачи!

Важная информация.

если сервис Google Play завис или не запущен, то fcm return token = null

Источник

Android Push notification using FCM (Firebase Cloud Messaging)

What is FCM ( Firebase Cloud Messaging) ?

Simply we can say FCM ( Firebase Cloud Messaging) is a new version of GCM ( Google Cloud Messaging).
It is a cross-platform messaging solution that lets you reliably deliver messages at no cost. Using FCM, you can send notification messages to drive user re-engagement and retention.

FCM (Firebase Cloud Messaging) Project setup on Firebase Console

Go to Firebase Console and create a new project

One popup will appear. Provide your app name (Project name) and country and click on CREATE PROJECT button

To implement Firebase to your Android app, click on Add Firebase to your Android app

Now enter your project package name and click on ADD APP to register your app

Download google-services.json file and click on CONTINUE button

Now click on FINISH button and complete your project setup on Firebase Console

Add FCM (Firebase Cloud Messaging) to Android app

Copy google-services.json file, go to your Android Project and paste it in app folder.

Go to project level (root level) build.gradle file and add the following code into dependencies

Now go to app level build.gradle file and add the following lines

Sync your project

Now create MyFirebaseInstanceIDService.java class

Now create MyFirebaseMessagingService.java class

Give the INTERNET permission and define both above services into AndroidManifest.xml

Now run your application and check your logcat and you can find TOKEN

Send your first notification message

Go to Firebase Console and click on your project (e.g. FCMDemo)
Now click on Notifications

Now click on SEND YOUR FIRST MESSAGE button

Type your message, select your app and click on SEND MESSAGE button and you will get your first notification on your device.

shaktisinh/android-push-notification-using-fcm

android-push-notification-using-fcm — Android Push notification using FCM (Firebase Cloud Messaging)

If you like this article please like this and subscribe it. If you have any doubt feel free to ask on comment. Follow me on twitter. Your appreciation means lot to me. Thank you.

Techsuzu

App development | Web development | WordPress development |…

Источник

Complete Guide on Sending Push Notifications on Android — Using Firebase

Holla! 👋, I will explain how to send push notifications on android using Firebase Cloud Messaging .

Push notifications are messages that pop up on a users device. A user can see these notifications without having to be on the app. This is important for users retention.

WHAT WE ARE BUILDING

We are simply going to build an app that lets a user input a message and send a push notification to that user containing that message. Simple! 😄

This is how the final app will look like

OnClick of that button

• Push Notification is sent to the user which contains the message you inputted

1. Firebase (Cloud Messaging)
2. Kotlin (For Android)
3. NodeJS (Backend)
4. Android Studio IDE

• Set up android studio
• Set up firebase project
• Add dependencies
• Set up Hilt And Retrofit
• Set Up Firebase Cloud Messaging
• Build view
• Setup Repository ViewModel and View
• Set up our backend with NodeJS

Alright, lets see each of them, one by one

SET UP ANDROID STUDIO

• First download android studio and install.
• Create A New Project — Choose Empty Activity
• Name your project anything, I named mine Firebase Notification Android
• Click Finish

We are using MVVM architectural pattern for this project

• Create 7 new packages name them — di , firebase , helper , model , view , viewmodel , network
• Move MainActivity to the view package

SETUP FIREBASE PROJECT

• Go to https://console.firebase.google.com/
• Sign in and click on Add Project
• Enter the name of your project — Name it anything,
• Click Continue
• On the Google Analytics page, Click Continue
• Choose a Google Account — Select Default Account For Firebase
• Click Create Project
• You will see — “ Your new project is ready ”
• Click Continue

Congrats, you have successfully created a firebase project. Now, lets link the project with our android app

Connecting Firebase With Android

• On your console home page click on the Android Logo

• Android Package Name — Go to your Manifest.xml , copy the package and paste it there, it should be something like this — com.name.firebasenotificationandroid
• App Nickname — Put anything there
• Debug Signing Certificate — Go to Android Studio , Click on gradle — Tasks — Android — signingReport — Copy the SHA-1 key and paste

• Click on Register App
• Download google-services.json and paste in you project folder app directory

• Add all the necessary firebase dependencies
• Sync project and you are done 👏

This app makes use of coroutines, hilt, retrofit, cloud messaging etc.

• Open your build.gradle(app) file and add them

Open build.gradle(project) add hilt class path

• Create 2 new class under di package name them — AppModule and MyApplication
• AppModule — This class is used to perform injection to types such as interfaces and classes from external libraries which we do not own e.g Retrofit.

• MyApplication — This class extends Application class. This will generate all the needed hilt codes and serve as a dependency container. It should look like this.

• Finally, go to your Manifest.xml file, in the application tag add android:name=”.di.MyApplication”

• Under helper package, create a class called EndPoints

EndPoints — A class where our base url and all api calls endpoint resides

• Under model package, create a class name AuthResponse
  AuthResponse — A class that models the response gotten from the server so we can take proper action

• Under the network package, create an interface called ApiService and 2 new classes, name them — ApiDataSource , BaseDataSource

ApiService — An interface where we will make a Post Request to our server to save a user’s name and notification token.

ApiDataSource- A class that exposes the ApiService so that we can use it in our repository

We are done with retrofit and hilt.

SET UP FIREBASE CLOUD MESSAGING

• Under firebase package, create a new class — MyFirebaseMessagingService — This class extends FirebaseMessagingService that handles messages, recieving notifications in foreground, receiving data payload, sending up stream messages

• Under helper create an object — Utility
  Utility — A utility class with a function that builds our notification — Handling stuffs such as — action when a user taps on the notification, customizing look of notification e.t.c

• Open Manifest.xlm , before the closing application tag, add this

• Add a default notification icon,color and channel, add to manifest.xml within the application tag

That should be all for configuring cloud messaging

Open main_activity.xml and use this code

Okay, now we have our not so beautiful view and everything set up, now lets set up our repository and viewmodel.

Setup Repository, ViewModel and View

• Open viewmodel package, create 2 new classes — MainRepo and MainViewModel
  MainRepo — This class serves as a source of data for our viewModel to consume.

MainViewModel — This class communicates with the repository, the result from the api call is then returned as a LiveData (Lifecycle aware) which is then observed by our view (MainActivity)

Here’s what this class does

• Get the views through ViewBinding
• Initialize the views
• Listen to click even on the button
• Communicate with viewModel to register the user
• Observe the data from the viewModel and display appropriate messages

SET UP NODEJS BACKEND

• Go to your firebase console, click settings icon -> Project settings

• Switch to Service Account tab, Click Generate new private key
• Confirm and download it
• Now create a folder in your pc, navigate to that folder with your terminal
• npm init and fill in all required details. This will create a package.json file
• npm i firebase-adminon your terminal to install firebase dependency
• Also npm i express and npm i bodyparser
• Create a config file

Okay, we are done. Take a deep breath! 😫

This is a link to the complete project, please check it out

Источник

Внедряем кросс-платформенные пуш-уведомления: начало

Добрый день! Меня зовут Владимир Столяров, я бэкенд-разработчик в команде Клиентские коммуникации в ДомКлике. В этой статье я расскажу о том, как внедрить кросс-платформенные пуш-уведомления. Хотя про это уже написано немало, я бы хотел рассказать о некоторых нюансах, с которыми нам пришлось столкнуться в процессе внедрения. Для лучшего понимания происходящего также напишем с вами небольшое веб-приложение, способное принимать пуши.

Для начала нужно понять, куда мы вообще хотим отправлять пуши. В нашем случае это веб-сайт, iOS-приложение и Android-приложение.

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

• У Firefox он называется Mozilla Push Service. Его исходный код и спецификация протокола открыты, чем мы позже воспользовались.
• У Chrome это Google Cloud Messaging (не Firebase Cloud Messaging, что можно увидеть по именам доменов в исходном коде), и так далее.

Хорошая новость для нас в том, что веб-пуши стандартизированы IETF (https://datatracker.ietf.org/wg/webpush/documents/), и поддерживать разные форматы API для каждого браузера как на клиенте, так и на сервере нам не придется.

Теперь рассмотрим устройства на базе Android. Здесь есть несколько вариантов:

• Если в системе установлены Google Apps, то можно воспользоваться Firebase Cloud Messaging.
• Если у вас устройство от Huawei без Google Apps, то можно использовать Huawei Push Kit.
• Можно написать собственный пуш-сервер или воспользоваться готовыми проектами, например, https://bubu1.eu/openpush/, благо открытость платформы позволяет.

Далее идет iOS. В отличие от Android, способ отправить уведомления на устройства Apple всего один — использовать Apple Push Notification service (APNs).

Может возникнуть логичный вопрос: неужели придется поддерживать всё это многообразие стандартов, API и прочего на серверной стороне? На самом деле, всё не так уж и плохо, так как Firebase Cloud Messaging, помимо отправки на Android, покрывает еще и веб-пуши и работает с APNs. Так мы пришли к следующей схеме: на устройства Huawei без Google Apps отправляем через Huawei Push Kit, в остальных случаях пользуемся Firebase Cloud Messaging.

Несмотря на многообразие стандартов и сервисов, схема работы будет примерно одинаковой:

1. Клиент подключается к пуш-серверу и получает уникальный идентификатор — токен.
2. Клиент отправляет токен серверу конкретного приложения, чтобы стать связаным с учетной записью пользователя.
3. Сервер приложений начинает по полученному токену отправлять пуши для конкретного пользователя.

Попробуем написать тестовое приложение

Для начала просто получим пуш-токен от Firebase и попробуем отправить пуш. Нужно зарегистрировать проект в консоли Firebase и получить конфигурацию для веб-приложения. Для корректного функционирования будет нужен локальный HTTP-сервер с передачей статики.

Сделаем страницу с одной кнопкой и необходимыми скриптами:

Также потребуется скрипт сервис-воркера. По умолчанию он подгружается автоматически по пути /firebase-messaging-sw.js . Для начала будем использовать готовый скрипт отсюда.

Открываем страницу, нажимаем на кнопку, разрешаем уведомления в браузере и копируем отображенный токен. Для удобства работы с API вручную можно создать долговременный ключ сервера (не сервисный аккаунт). Делаем простой запрос:

Тут есть важный момент, о котором можно забыть: пуш-токен никак не связан с пользователем приложения, он связан с конкретным получателем (т.е. с клиентской конфигурацией). На мобильных устройствах он связан с конкретной инсталляцией приложения.

Посмотрим, что нам приходит в браузер. В документации описан колбэк setBackgroundMessageHandler . Модифицируем сервис-воркер, добавив в конец файла код:

Открываем консоль сервис-воркера, снова отправляем пуш… и ничего не видим в консоли, хотя уведомление отобразилось. Почему же? Ответ в есть в документации:

Note: If you set notification fields in your message payload, your setBackgroundMessageHandler callback is not called, and instead the SDK displays a notification based on your payload.

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

Тем не менее, можно это обойти, обрабатывая входящие пуши вручную. Поменяем содержимое firebase-messaging-sw.js :

Здесь мы считываем полезную нагрузку в json и парсим ее в js-объект, который будет выведен в консоль, заодно показывая уведомление. Обратите внимание на waitUntil внутри обработчика: он нужен для того, чтобы сервис-воркер не завершил работу до окончания асинхронного вызова onPush .

Теперь добавим пользователей в наше приложение

Для удобства заведем новую страницу:

Нам понадобится простенький бэкенд, писать будем на Go. Тут приведу только пример кода, отвечающего за хранилище токенов:

В бэкенд также добавлен код отправки пушей конкретному пользователю.

Базово мы обеспечиваем следующую функциональность:

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

Опишу несколько важных моментов, на которые мы наткнулись уже на практике (они отражены в примере):

• Пуш-токены имеют ограниченный срок жизни, однако узнать его из самого токена, на первый взгляд, невозможно. Судя по коду firebase-js-sdk, этот срок чуть больше недели, так как колбэк на обновление токена onTokenRefresh вызывается раз в неделю.
• Разные пользователи могут прислать одинаковые пуш-токены. Такое возможно в случае, если запрос на инвалидацию в Firebase не прошел успешно. Для решения этой проблемы мы в данном случае меняем владельца токена.
• У пользователя может завершиться сессия без явного логаута. Т.е. пользователь больше не авторизован, однако уведомления продолжают поступать. Способ решения этой проблемы зависит от архитектуры приложения. Мы при отправке пуш-токена на сервер сохраняем идентификатор пользователя еще и локально, при каждой загрузке страницы сверяя его с ответом на запрос о текущем пользователе. Если значения различаются или пользователь не авторизован, то пуш-токен инвалидируется. Однако у такого подхода всё же есть один недостаток: инвалидация происходит только в случае загрузки страницы сайта.
• Сохраняйте платформу, с которой получен токен. Это поможет при дальнейшей кастомизации: например, добавить возможность ответа в чат прямо из пуша (в Android/iOS можно, в браузере — нет), кнопки и прочее.

И вот, грабли собраны, доработки выложены в прод. Пуши ходят… или не ходят? Самое время поговорить про

Надежность

Никаких методов подтверждения доставки от клиента серверу приложений изначально не предусмотрено, хотя в Huawei над этим задумались и сделали. Поэтому нам придется реализовывать эту функциональность самим. Первое, что приходит в голову — отправлять на сервер HTTP-запрос при получении пуша. Для этого нам потребуется идентифицировать каждый пуш, благо и Firebase, и Huawei это позволяют: можно пробросить произвольные данные при отправке уведомления.

Идея следующая: мы генерируем одноразовый токен подтверждения (в нашем случае это просто UUID) и отправляем его в пуше. Клиент при получении и показе пуша делает HTTP-запрос, в который включается присланный токен подтверждения. Немного дорабатываем бекенд и firebase-messaging-sw.js :

И если с вебом нам хватило такой простой доработки, то с мобильными устройствами всё несколько сложнее. Помните про замечание в документации о setBackgroundMessageHandler ? Так вот, дело в том, что в Firebase (да и в Huawei) есть не совсем очевидное (по API) разделение на, условно, информационные пуши (если есть поле notification ) и data-пуши. По задумке, информационные пуши никак не обрабатываются приложением и на их основе сразу формируется уведомление, а data-пуши попадают в специальный обработчик и дальше приложение решает, что делать.

Если при получении веб-пушей с ними можно работать до показа, отказавшись от firebase-js-sdk в сервис-воркере, то в Android так не получится. Поэтому для Android мы перенесли всю нужную информацию исключительно в data и перестали отправлять notification , что позволило нам реализовать подтверждение доставки.

Для APNs же достаточно просто выставить mutable-content в 1, и тогда при обработке пуша можно будет выполнять некоторый код, но с довольно серьезными ограничениями, хотя этого вполне достаточно для простого HTTP-запроса. Собственно, именно из-за ограничений iOS при подтверждении пуша не задействуется пользовательская сессия, а используются одноразовые токены.

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

Мы же используем механизм подтверждения следующим образом: для некоторых типов уведомлений, если не дождались подтверждения через, скажем, 15 минут после отправки, отправляется смс. А чтобы исключить случай, когда после смс приходит пуш, можно выставить TTL при его отправке.

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

• Android (исключая Huawei) — 40 %
• Web — 50 %
• iOS — 70 %

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

Итоговая архитектура получается примерно такой:

Полную версию проекта можно взять на GitHub.

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

Источник