Android push notification without google
Опишу здесь установку MicroG сервисов уведомлений (дают синхронизацию с Google Firebase Cloud Messaging)- альтернативные гугл пуш-уведомления. (MicroG уже знакома всем кто пользуется Youtube vanced).
Итак, установка и настройка очень проста:
1. Делаем сброс до завосдких. (лучше сделать, потому что все установленные апк не запустятся и их нужно будет переустановить).
2. Устанавливаем Services Core. Все три апк качаем сами с официального сайта MicroG https://microg.org/download.html
3. Устанавливаем Framework Proxy.
4. Устанавливаем FakeStore.
5.Открываем MicroG Settings — даём ей все разрешения и отключаем оптимизацию батареи.
5.1. Здесь же добавляем свой аккаунт гугл.
5.2. Здесь же включаем Device Registration, Cloud Messaging и SafetyNet.
6. Перезагружаем девайс.
7. Снова заходим в MicroG Settings и проверяем статус в настройках Cloud Messaging.Если там написано «отключено», тогда в звонилке набираем: *#*#2432546#*#* и перезагружаемся. Снова проверяем статус, должно быть написано «подключено». Возможно придётся повторить этот пункт еще несколько раз. У меня получилось с первого на view30 pro.
8. Скачиваем Outlook с авроры, добавляем туда аккаунт почты, в настройках энергосбережения убираем галочку с автоматический. Проверяем, наслаждаемся. Осталось проверить пуш от сбера.
п.с. Ютюб вансед ставится и работает при этом способе без косяков. (ставим необходимый ванседу microG, сам вансед, в настройках ванседовского microG не забываем отключить регистрацию в Гугл).
—————
Уведомления теперь отлично приходят на почту Outlook и Авито, до этого никакие способы кроме чат партнера, у меня не решали проблему с мёртвыми пушами на этих приложениях.
Сообщение отредактировал lesnikov88 — 24.05.20, 18:00
Источник
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 уведомлений (таким образом исключается ситуация банального разрыва соединения, таймаута и пр.);
- необходимо прогонять данный алгоритм периодически (например, раз в неделю, или после обновления ОС на устройстве).
Всем добра. И поменьше подобных костылей.
Источник
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
- Firebase (Cloud Messaging)
- Kotlin (For Android)
- NodeJS (Backend)
- 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
Источник