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