Комментарии 81
Зачем что-то делать самому, когда есть телеграм, инстаграм и тп?
Зачем так сложно, когда есть OneSignal?
Там же вообще в 3 строчки можно отправлять себе сообщений откуда угодно… Не увидел в статье описания преимуществ Firebase, а ставить отдельное приложение для уведомлений, как то не очень хочется.
Минусящих — с новым годом! :)
про отдельный клиент, который прям вот только для уведомлений, речи не было. добавить можно в любое уже имеющееся, или планируемое приложение.
Вы говорите «В этом туториале я рассмотрю пошагово, как отправлять со своего сервера уведомления на свой (или не свой) смартфон» — для решения данной задачи есть очень много более простых способов, но, если вы то оказывается делаете упор на получение этих сообщений собственным приложением под андройд, и тут вообще как бы совершенно о другом — о разработке взаимодействия вашего сервера и вашего же приложения. На сколько я понял это из других камментов и перечитывания части про клиента.
операционка (или оболочки) любят глушить все сокеты в фоновых процессах. и сам гугл настоятельно советует использовать для такого рода задач GAPS.
я так понял, что для того, чтоб избавиться от GAPS, надо писать свой аналог, и ставить его обязательно под рутом. а это уже несколько иной уровень хардкорности.
да и в целом, без GAPS смартфон превратится в некий аналог тыквы, что устроит ну очень малое количество пользователей.
Скоро может оказаться, что проще реально свое приложение написать.
Его хотя бы никто блокировать не будет.
Почему просто не использовать Telegram Bot API ?
Больше способов хороших и разных.
Особенно в нашей стране, в которой уже носятся с идеей забанить Telegram.
ИМХО, разумеется.
Вот "свои почтовые серверы" и есть аналог бота на Telegram. А то что тут сделано — скорее аналог своего почтового клиента. Поднимая облачные хранилища, свой клиент к такому хранилищу не пишут.
"Послать себе сообщение" подразумевает многое. В частности способ его прочитать, способ организовать безпроблемную отправку. Telegram бот делает всё это простыми средствами. Firtebase — требует выполнения многочисленных действий и нескольких длительных операций (например предварительно запросить токен у Firebase и обработать ошибки получения токена, которые случаются и почему-то не обрабатываются в статье).
а по поводу, почему в коде не предусмотрена обработка фейлов — поверьте, в реальных программах всё обрабатывается. тут умышленно всё изображено в максимально упрощённом виде.
В телеграмм и bot-api и клиент-апи, то есть вы можете написать свой клиент и своего бота, без закладок.
Опять таки — вы говроите, что нужно установить сам телеграм, но ведь ваше приложение тоже нужно установить? Или опишите чуть подробнее, чем google API лучше чем нативная поддержка sms, или mail, который есть в каждом телефоне, или даже тот же телеграм?
не понимаю, про какое «моё» приложение вы говорите. я предлагаю способ, с помощью которого каждый сможет встроить пуш технологию в его собственное мобильное приложение.
если вы в целом, про то, что невозможно получать уведомления без приложения, то да, хоть какое то приложение да нужно.
каких то особенных преимуществ, чем описанный способ вроде нет. разве что мелочи вроде кастомного звука, или мигания цветным светодиодом, у кого он есть.
но мой способ будет очень актуален для тех, кто собирается разрабатывать какое-то своё комплексное приложение, в которое до кучи можн будет добавить пуш. по которому помимо просто уведомлений можно и данные гонять в приложение с сервера.
по которому помимо просто уведомлений можно и данные гонять в приложение с сервера
Скажите плиз, а какой обьем данных можно передать на клиент?
Можно ли передать что-то вроде json в пару килобайт?
А вообще не понимаю почему статья в плюсе, это ведь как обычный урок по андроид разработке или это из-за названия статьи?
Отправить можно на смартфоны с Android, iOS и в браузеры с поддержкой Push API (на сегодня это Chrome, Firefox и их производные).
Что-то я потерялся в Android и не заметил как отправлять в iOS и браузер…
в целом мне показалось, что вся сложность именно в отправке (90%), с приёмом у меня не возникло совсем никаких проблем (10%). весь приём в андроид приложении заключался в добавлении «пары строк и пары классов».
думаю сильно не ошибусь, если предположу, что и на других платформах с приёмом не будет шибко больших проблем.
сегодня хорошей альтернативой служат всякие IoT радиомодули, LoRa и т.п. дальнобойность тоже может измеряться километрами, но вот скорость — аховая. для задач уведомлений — подойдёт.
(про пейджеры ничего не напишу, они уже через сотовую сеть работали)
$payload = '{
"to" : "cGAFgPJGf-s:APA91bF**...**aEVM17c9peqZ",
Вот жеж блин Гугл! Был же GCM, все нужды покрывал, ну зачем без конца все менять, усложнять, накручивать? А главное, даже в статье сказано, что вся эта сложность бесполезна, если оболочка режет фон, а нового реально ничего. Просто раз в год-два приходит новый перспективный молодой и энергичный дурачок и переделывает все до основания, в результате те же яйца, вид сбоку, но 50 дополнительных переключателей и добавлена так нужная всем возможность разогревать сосиски, но не больше 1 в час. Собственно это касается и других сервисов гугла, простоты для разработчика как пользователя библиотек и сервисов там не ищут. Поэтому, если есть возможность, надо все делать самому, иначе погрязнешь в постоянных переделках под гугл, ведь сохранять интерфейсы для обратной совместимости это ж не круто.
как оказалось, уведомления это лишь верхушка айсберга, там целая туча всякой аналитики через тот же канал гоняется, вплоть до того, как часто вы чихали, с какой силой и продолжительностью. заботятся о вас и вашем здоровье.
но с какой-то стороны перманентно мутирующие интерфейсы это даже благо, например они таким образом не дают остаться без работы (а следственно и без хлеба) толпам программистов.
Тезис: уметь делать нечто независимо и самостоятельно — правильно, полагаться на вечность и бесконечность поделок 3,4,5...15й стороны — неправильно.
P.S.: автор — молодец.
первая мысль от таких комментариев и была — стартаперы с вейпами, смузи и спиннером. побоялся, что шапками забросают.
рад что на хабре ещё есть и адепты старой школы ) батя может в СИ.
p.s. ничего не имею против новой школы, когда то и я был новой школой, писал на новомодном PHP3, и вызывал недоверчивые взгляды у коллег.
Спасибо автору. В любом случае есть полезная информация
мне ответили (выше), что всякие фейсбуки и без рутов реализуют такие фичи. но так глубоко в андроид разработку я не погружался, поэтому подтвердить или опровергнуть не могу.
система нещадно душит соединения фоновых процессовА зачем нужно соединение? Разве нельзя попросить систему «разбудить» нас, когда придет, например, UDP-сообщение на некий определенный порт? Из описанного в статье можно сделать вывод, что сетевой стек продолжает работать, даже когда телефон «спит». Единственная проблема, которую я тут вижу, это отправка любого сообщения с определенным интервалом на сервер, чтобы «пробить» NAT. По-моему, сейчас никто из ОпСоСов не предлагает статический адрес… :-(
если интересно, для nat-to-nat соединений прекрасно работает en.wikipedia.org/wiki/UDP_hole_punching. да, понадобится всё-таки сервер посредник, но исключительно для обмена адресами и портами.
а для соединения nat-to-real никакие хитрости и не нужны. достаточно поддерживать соединение отправкой пустых keepalive пакетов по UDP, чтоб всякие промежуточные прокси не посчитали соединение покинутым и не перестали его обслуживать.
а в таких вещах как push, постоянное соединение поддерживать невыгодно с точки зрения батареи. поэтому там реализовано так:
— клиент подключается к серверу
— отправляет свои (скопившиеся) сообщения на сервер
— принимает с сервера скопившиеся сообщения
— отсоединяется от сервера
— снимает питание с сетевухи (модема), чтоб по человечески поспать
поэтому на спящий смартфон сообщения не приходят мгновенно, а только когда смарт просыпается, и чекает сервак. и эти интервалы разные, в зависимости от предпочтений ОС по энергосбережению.
bind(...)
на интересующий нас порт. Я просто не знаю, как это делается в Android / iOS, описываю, как бы я это делал на десктопе.Из личных наблюдений, Wi-Fi на моем телефоне не отключается сразу, как только я заблокировал экран. Значит, некая микросхема, ответственная за сеть, имеет возможность послать прерывание процессору, когда получен новый пакет.
Конечно, это можно проверить с помощью Wireshark / tcpdump, но мне как-то лень.
и у WiFi и модема очень разные стратегии по энергопотреблению. замечал, что на планшет, после перевода в спящий режим я еще могу заходить несколько секунд, около 20. потом рубит. но это планшет на Win10, на андроиде вероятно по другому. яж говорю, все эти стратегии, когда отрубать питалово с модемов и сетевух, отданы на откуп вендорам, и они сами, на своё усмотрение их реализуют, единого стандарта нет.
даже могут менять в версиях прошивок. отсюда и отзывы пользователей «новая прошивка жрёт батарею!!1». это не прошивка жрёт, а сетевуха стала реже отключаться.
думаю, проверить сетевым анализатором это будет самый верный и быстрый способ. я только знаю, что гугл рекомендует настраивать фаерволы на порт 5228 (дополнительно 5229 и 5230), чтоб не блокировали их на исходящий. (например)
Исходящий трафик, безусловно, есть. Как-то же телефон должен себя регистрировать. Проверю, если будет время. Проблема только в том, что у меня заблокированы все уведомления :-) Но если телефон, как вы говорите, сам ходит на сервер, то я это увижу. Такие уведомления только уже правильно будет называть не push, а pull.
гугл ещё на ранних этапах понял, что каждое второе приложение будет создавать коннект со своим сервером, и вся эта вакханалия будет жрать батарею и сокеты. и решили всё это дело объединить в единую точку входа, и интегрировали её в GAPS. и получается, да, именно гапс определяет с какой частотой ходить на сервера, и чекать что там новенького.
с GPS такая же петрушка. тоже как-то писал приложение с GPS, много интересных поведений начитал. там тоже все попытки душить в фоне GPS мотивировали жёром батарейки.
1. Снимает вопрос безопасности, позволяя приложению не иметь открытых портов.
1.1 Большинство мобильных устройств не имеют адресов Internet(белых адресов) и таким образом пуш на них вообще не возможен.
2. Снизить энергопотребление устройств. У сипа пуш весьма условный. Это не сервер что-то шлет на клиент, а клиент с завидным постоянством спрашивает сервер «ну как есть, что для меня?».
Никто не запрещает, бери пиши свой FCM, опрашивай свой сервер каждую секунду. Для этого в андройде есть сервисы. Там есть свои нюнасы, как и в целом во всей мобильной разработке.
Автору тут уже n раз намекнули, что каждой задаче свой инструмент. FCM это исключительно удел разработки под android и кстати ios, тк он и на apple шлет уведомления. И если нет задачи писать свое мобильное приложение, то лучше использовать любой другой более выскоуровневый сервис.
also, забавный нюанс. помимо упомянутых web api, сервис еще и через xmpp может принимать запросы от сервера. У гугла на удивление очень подробная документация с картинками к этому сервису.
Большинство мобильных устройств не имеют адресов Internet(белых адресов) и таким образом пуш на них вообще не возможен.Какой-то адрес они все-таки имеют. И, зная, например, в случае с TCP / UDP номер порта, до них можно достучаться.
У сипа пуш весьма условный. Это не сервер что-то шлет на клиент, а клиент с завидным постоянством спрашивает сервер «ну как есть, что для меня?».Для банальных INVITE или MESSAGE именно устройство пользователя выступает в качестве сервера. Телефон не спрашивает каждые N секунд, «а не звонит ли мне сейчас кто-нибудь». SIP приводился просто как пример протокола, позволяющий клиенту свободно путешествовать по сети. Исключительно для Push-уведомлений я его использовать не предлагаю (хоть это и возможно).
И если нет задачи писать свое мобильное приложениеТак о чем еще идет речь?
У гугла на удивление очень подробная документация с картинками к этому сервису.В этой подробной документации с картинками на удивление нет ни капли информации о том, как это все реализовано на устройстве. Только 100500 способов связаться с их сервером, а также получить уведомление от системы.
Какой-то адрес они все-таки имеют.
нынче это не так, сотовые операторы в большинстве случаев даже серого IP не дают. натят.
Какой-то IP-адрес ОпСоС вам все-таки выдает, и он точно не «серый», поскольку такие адреса в Интернете не маршрутизируются. Другое дело, что этот же адрес могут получить одновременно несколько абонентов. Но при этом вы можете связаться с нужным клиентом используя «адрес», который лежит на уровень выше. Например, TCP порт. Иначе как вы получаете от сервера ответ на свой запрос? :-) Можно пойти еще дальше. На shared-хостингах у вас с соседями не только один IP-адрес, но также и один TCP-порт (80). При этом запрос по-прежнему маршрутизируется на нужный сайт благодаря HTTP-заголовку Host.
TL;DR; Нет никакой проблемы выйти на связь с нужным телефоном. Не верь, читатель, слепо всему, что пишут в комментариях на Хабрахабре.
также я писал про то, что нат может преждевременно закрыть активный сокет, если по нему слишком долго не будут ходить пакеты. поэтому, чтоб он не закрывался, гоняют пустые пакеты, keepalive.
я посмотрел ваш профиль. верю, что разбираетесь в сетях. но и мне доводилось писать сетевые драйверы на микроконтроллеры. о протоколах MAC, IP, TCP, UDP и ICMP знаю не по наслышке. Wireshark'ом пользовался, когда его ещё не было )) была под 98-ми виндами прога Commview.
IP адрес в паре с портом называется сокетомКакой порт имеет Unix- или raw-сокет? :-) Отвечать не обязательно, но это то, что меня смутило в вашей терминологии (как ОпСоСы «даже серого IP не дают», а что тогда 100.64.0.0/10 у большинства провайдеров, не просто «натят», а «маскарадят» и т. д.), поэтому я на всякий случай и решил разжевать все подробно, чтобы точно не осталось вопросов. Ну и кроме того это не личная переписка, так что у неокрепших умов, читающих наши комментарии, может сложиться неверная картина мира.
Wireshark'ом пользовался, когда его ещё не было )) была под 98-ми виндами прога Commview.Вы могли пользоваться Wireshark'ом до его появления только в случае, если вы сами являетесь его разработчиком. Опять у меня трудности с понимаем вашей терминологии (я этот класс программ, как и большинство людей, называю снифферами, а не Wireshark'ами).
Критику мою слишком серьезно, конечно, воспринимать не стоит. Мне, например, как-то никогда в жизни не приходилось писать своего сетевого драйвера (в отличии от вас).
статься уже в архиве, никто в такие дебри не будет заходить и читать каменты. теперь только ищущие по теме (для кого я собственно её и писал) будут её находить и читать. хипсторы на гироскутерах слава богу уехали.
Автору тут уже n раз намекнули ...
ох, теперь я понимаю, что надо было ЯВНО написать, что такой способ актуален ТОЛЬКО если вы планируете прикрутить уведомления к своему УЖЕ существующему приложению. это сняло бы половину комментариев с недоумениями.
Но тема очень интересная. Я сам недавно прошел путь отправки пуш сообщений на телефон, но только задача частью написания мобильного приложения и серверного бэкэнда.
Были те же мысли с оттенком паранойи, зачем зависеть от чьего-то сервиса, почему не написать все самому? А еще был вопрос, а из чего собственно выбирать?
Насколько я понимаю практически все мобильные приложения используют FCM. Альтернативой является собственная реализация MQTT, но это задача весьма не тривиальная и требует постоянного бэкграунд процесса, который на андройд потенциально может быть закрыт системой, а на IOS такого понятия как постоянно работающий бэкграунд процесс и вовсе нет.
PS. Наверное, неплохо бы вам еще парсить ответ на отправку сообщения в примере, хотя бы статус.
А вот тут есть описания проверки токена
firebase.google.com/docs/auth/admin/verify-id-tokens.
я в примерах только в одном месте поставил наспех написанный, максимально кратко, пример как проверять ответы «parse answer JSON (lame)». очень не хотелось раздувать код.
по себе знаю, как тяжело читать чужие сорцы, когда суть разбавлена всякой мишурой эксепшенов и прочего. я же тут не выпендриваться пришёл, какие крутые у меня парсеры и обработчики исключений. я был бы благодарен всем кто пишет примеры, если бы они тоже старались акцентировать внимание в примерах максимально на сути.
ну и да, я не старался написать прям уж исчерпывающий мануал, со всеми нюансами и аспектами. те кто уловят суть, думаю без труда и разработают вопрос, до той степени как им надо.
Я не спец в php, но ваша обработка вполне достаточна чтобы понять успешно отправлено сообщение или нет.
if ($line[0] != 'HTTP/1.1 200 OK') die($line[0]);
400 будет в случае если, что-то не так в отправляемом сообщении, 404 если не так с токеном клиента.
<uses-permission android:name=«android.permission.RECEIVE_BOOT_COMPLETED» />
Пара способов отправить уведомления на смартфон со своего сервера