Comments 16
Все упоминания и реализации push непременно связаны с fcm. Да, это, конечно, удобно, что не нужно заморачиваться с сервером и разницей реализации в разных браузера, но этот вариант не особо подходит для целей, когда одним из требований является работа только с локальными ресурсами (например, когда web недоступен).
Плюс, хотелось бы понимать что происходит «под капотом» библиотек, которым безоговорочно доверяют.
К сожалению, без FCM это будет сделать довольно тяжело и не будет нативной поддержки Chrome/Android (они жестко завязаны на FCM), да и сама технология подразумевает использование 3rd-party серверов.
Про то, что происходит "под капотом" у Firebase SDK на клиентской стороне (в браузере) я тоже планирую написать.
Отображение же уведомлений что в бразуерах, что на Android можно делать независимо от собственно пуш-системы. Как там у iOS с этим дела обстоят, сходу не могу сказать. Но для этого нужно будет поднимать собственную инфраструктуру, хотя те же OpenPush или AutoPush (существует аж в трех вариантах) могут с этим помочь
Я реализовывал серверную часть на php с помощью вот этого компонента minishlink/web-push. Задача клиентской части в этом случае запросить разрешение на подписку и выслать на сервер три параметра endpoint, publicKey и authToken, это данные одного конкретного получателя.
Сервис воркер остается примерно таким же, как у автора.
Эти технологии решают несколько иные задачи. Если вебсокеты/sse нужны для обновления состояния приложения в реальном времени, то пуши — скорее для оповещения пользователя. Да, можно получать события по sse или вебсокету и показывать уведомления, однако с этим есть несколько проблем:
- Нужно строить свою инфраструктуру почти что с нуля, это довольно дорого и долго
- Пуш-уведомления приходят через одно единственное соединение на весь браузер или мобильное устроиство. Если в браузере никто не мешает перенести подключение в сервис-воркер, то в мобильных устроиствах это, во-первых, не всегда возможно (насколько я знаю, в iOS очень жесткие требования по фоновой работе), во-вторых, ускоряет разряд батареи
Спасибо за ответ, всё по делу. по сути оповещения пользователя ту же задачу решают — обновление данных приложения. Отложенные или рилтайм — это уже вопрос реализации протокола и инфраструктуры. Я подобную систему делал на го, не могу сказать что это было мега дорого и проблематично, но конечно от задачи зависит. По поводу хттп соединений — современные фронтенд приложения их много открывают и ни разу на них не экономят. Мне трудно оценить стоимость хттп коннекта в единицах времени работы аккумуляторной батареи, но по опыту разработки мобильного натив софта не заметил влияния. Если покажете бенчмарки, буду признателен.
Судя по тому, что я читал, там действительно за общение с сервером отвечает отдельный процесс, который при получении данных отправляет нужному приложению Intent. Про использование полуоткрытых соединений ни разу не слышал, да и это вроде как ошибочная ситуация. Точнее сказать сложно, так как сам в этом не разбирался. Если разберусь, постараюсь об этом написать.
Можете показать формат отправляемого уведомления, где разница между notification и data?
Вариант с notification:
{
"to" : "<token>",
"notification" : {
"body" : "Body of Your Notification",
"title": "Title of Your Notification"
}
}
Приходит вот так:
{"from":"514044135031","priority":"normal","notification":{"title":"Title of Your Notification","body":"Body of Your Notification"},"collapse_key":"do_not_collapse"}
Вариант с data:
{
"to" : "<token>",
"data": {
"key1": "value1",
"key2": "value2"
}
}
Приходит вот так:
{"data":{"key1":"value1","key2":"value2"},"from":"514044135031","priority":"normal","collapse_key":"do_not_collapse"}
Т.е. дело-то не в технологии как таковой. Альтернативы гугловскому firebase нет не потому, что там какая-то секретная волшебная технология, а потому, что тупо у сервиса права есть, которых нет у вашего приложения. И этот вопрос никак не проясняется на сайте OpenPush. Или я плохо искал?
Openpush лично не испытывал (включил в статью, чтобы было понимание о наличии альтернативных решений), но, скорее всего, вы правы и "оптимизацию батареи" для него придется отключать вручную для стабильной работы. И, кстати, "невидимые" для пользователя data-пуши используют иногда в том числе и для того, чтобы "разбудить" приложение (мы сейчас исследуем эту возможность)
А сегодня ещё и до MS Teams добрались (
Внедряем кросс-платформенные пуш-уведомления: начало