Доступен (https://github.com/gotify/server/releases) выпуск проекта
Gotify 2.0 (https://gotify.net/), в рамках которого развивается реализация сервера для доставки и приёма push-уведомлений с использованием протокола Websocket. На базе предложенного решения можно организовать самодостаточную систему доставки информационных сообщений или уведомлений о наступлении различных событий, работающую в режиме реального времени и выполняемую на подконтрольном оборудовании, без привязки к сторонним сервисам. Код написан на языке Go и распространяется (https://github.com/gotify/server/) под лицензией MIT. Для быстрого развёртывания сервера предоставляется образ для системы Docker. В качестве СУБД может применяться SQLite, MySQL и PostgreSQL.
В дополнение к серверной части проектом подготовлено android-приложение (https://github.com/gotify/android) для чтения уведомлений и интерфейс (https://github.com/gotify/cli) командной строки для автоматизации отправки уведомлений. Для получения сообщений и управления подписками предложен web-интерфейс (https://github.com/gotify/server/tree/master/ui). Для отправки сообщений предоставляется REST-API, а приём осуществляется при помощи WebSocket. Доступен API (https://gotify.net/docs/plugin) для расширение функциональности через подключение плагинов.
Предоставляются средства для управления пользователями сервера, клиентскими приложениями (подписчики, получающие уведомления) и приложениями для отправки. Привязка приложений, которые могут отправлять уведомления, осуществляется по токену (идентификатору канала), который генерируется через web-интерфейс. В простейшем случае в качестве приложений для отправки может использоваться утилита curl или cli-интерефейс gotify:
curl -u admin:admin -X POST https://yourdomain.com/application -F "name=test" -F "description=tutorial"
или
gotify push -t "my title" -p 10 "my message"Клиентские приложения (web-интерфейс и android-приложение) могут только получать и удалять сообщения, но не могут их отправлять. При наличии соответствующих полномочий через web-интерфейс также можно управлять подписчиками, генерировать токены для отправки и создавать новых пользователей. Каждое сообщение включает такие атрибуты, как содержимое, дата, заголовок, приоритет и идентификатор приложения (канала).
URL: https://news.ycombinator.com/item?id=19347848
Новость: https://www.opennet.ru/opennews/art.shtml?num=50285
Про батарейку тут уже говорили? Google Services хоть и бэкдор, но сделан таким образом, что батарейку не жрёт особо.
Вообще-то жрёт очень основательно (у меня без него смартфон 4 дня держался, с ним - три). Но да, гугл имел возможность использовать то, что не дал больше никому - управление пробуждением устройства,
Вообще-то у GCM нет никаких "эксклюзивных" возможностей. Насколько я помню, тот же самый функционал работает и в других приложениях (во всяком случае, работал во времена Android 4) — показываешь foreground-уведомление, открываешь сокет и начинаешь слушать. Как только в сокет что-то приходит — берёшь wake lock. Плюс в новых версиях нужно добавить приложение в исключения Doze."Спящий" режим это просто один из уровней энергопотребления в процессоре, соответственно никто не мешает читать в нём из сокета, и когда что-нибудь придёт — выходить из него взятием wake lock. Насколько я понимаю, Doze реализован через что-то вроде cgroups, и в нём приложение действительно "замораживается", так что без добавления процесса в исключения пользователем не обойтись.
Естественно, вся эта махинация связана с привлечением внимания пользователя, и объяснением ему, зачем твоему приложению перманентно висеть в трее и жрать батарейку. Троянско-шпионскому мусору, который в фоне шлёт логи твоих действий на сервер и делает скриншоты по команде с базы, выгоднее идти на поводу у Гугла. Но техническая возможность как таковая есть, и её пока никто не отнимал.
В четвёрке так и было. Гугл закрутил гайки в шестом, если не вру, убрав возможность разбудить устройство для всего, кроме системных приложений. Хотя о деталях могу врать. Может, добавление исключений к Doze это и исправило, не знаю.
>если не вру, убрав возможность разбудить устройство для всего, кроме системных приложенийтаки врете. Google Services с Firebase Cloud Messages как раз и могут хоть даже на 9м андрюше разбудить устройство и передать управление приложению. Без добавления оного в белый список дозы. А вот решение из заглавия темы явно будет требовать добавить прогу в белый список дозы иначе никто ему слушать вебсокеты и никого пробуждать не даст.
>не дал больше никому - управление пробуждением устройства,Не совсем. Управление подключением к сети, незаметной посылкой запросов, получением чего-то там... Всё совершенно не беспокоя "пользователя". Ага...
Смысл фреймворка сообщений Play Services не в том, чтобы *просто* не жрать батарейку, — любое другое приложение, будучи правильно написанным, может делать то же, что и GCM. Его смысл в том, чтобы принимать сообщения с минимальными возможными затратами ресурсов. Вместо 20 процессов, читающих из сокета в фоне, в системе будет один такой процесс (ну плюс пара отщепенцев, держащих foreground-уведомления, вроде скайпа).Прикол в том, что само отображение уведомления в трее не предотвращает сон, — оно нужно только чтобы система не прибила показывающий уведомление процесс. Когда устройство уходит в сон, процессор просто переходит в минимальный режим энергопотребления. При этом приложения продолжают выполнять код (но ооооочень медленно), и с помощью общедоступного API могут вывести девайс из сна (например, в случае прихода сообщения из сети).
Второй трюк здесь в том, чтобы не использовать keep-alive сообщения (ни TCP keeap-alive, ни протокольный PING). Если что-то отправлять или получать по сети, сетевой адаптер не сможет перейти в режим пониженного энергопотребления, и любая выгода от ухода в сон основного процессора будет сведена на нет. GCM просто открывает соединение и изредка проверяет, что какой-нибудь NAT-сервер по дороге его не прибил.
Всё это описано в официальной гугловской документации по снижению энергопотребления, и отдельные приложения, например некоторые почтовые и Jabber-клиенты, успешно используют эту информацию чтобы сидеть в фоне, не сжирая всю батарейку. Естественно, нужно чтобы сервер с тобой кооперировал: не слал всякий мусор и keep-alive в фоне, объединял соседние сообщения, не будил девайс каждые 2 секунды нормальной активностью.
Ну это классно, но наверно интересно 50/50
Все же как писали выше есть Apple Push Notification Service, а БЕЗ сертификата вы даже на "своем подконтрольном оборудовании" ничего не отправите на iOS и на Safari вроде как тоже.
А если у вас есть сертификат, то значит можно пользоватся и дальше Apple Push Notification Service.
Но в статье (и на картинке) ни слова ни слова об упомянутых Вами мобильной ОС и браузере.
Ну так на Android же я думаю без проблем Gotify доставляет push
При чем тут сертификат для APNS? Это абсолютно паралельная реализация (как и у яндекса, например). Висит демон и держит подключение на какой-то ваш сервер.
такое впечатление что в комментарии набежали маркетологи из Apple
Ну причем тут маркетологи, просто надо же на ВСЕ платформы доставлять уведомления.
Я бы с радостью пользовался НЕ APN, а чем то другим, если бы это "что то другое" доставляло push сообщения на iOS и т.п
Именно. Основной процент аудитории на iOS, так что без APN ты далеко не убежишь.
> Основной процент аудиторииЧьей и где?
PS: или... Вы вообще из какого года?
2019.
Большинство стартапов даже не делает версию для андроида - иос аппликуха (основное) и веб-сайт.
> Большинство стартаповМожно циферки и источник?
Бизнес-инкубаторы QD, Ingria. Циферки не дам - это из результатов общения. Субъективно, только 1 из 10 стартапов делает андроид приложение - для него достаточно веб-сайта.
> Бизнес-инкубаторы QD, Ingria.Последняя пишет про 41 резидента -- такие вещи тоже стоит хоть как-то указывать, выкатывая обобщения.
> Субъективно, только 1 из 10 стартапов делает андроид приложение
> - для него достаточно веб-сайта.Для меня это звучит как приговор Safari. :]
PS: если что, не держу ни ту сливопомойку, ни эту.
Михайл, никого не истересует количество аудитории. Важно качество и ее способность платить деньги, поэтому аудитория андроида часто даже не рассматривается.
> никого не истересует количество аудиторииИ много Вы лично платите пейсбуку, специалист по аудиториям?
Причём тут это?
Прост сравните сколько денег вокруг AppStore и GooglePlay. Банальный здравый смысл вам скажет: «сделаем приложение для iOS, а если хорошо пойдёт, то может как нить потом и для Андроида».
Банальный здравый смысл мне уже не раз подсказывал не бегать за деньгами. И далеко не всегда соглашаться, когда вдруг за мной начинали бегать они. Но такое самому понять надо -- кто-то так до смерти и гоняется за иллюзией бабла, подчас выкидываясь из-за оного из окошка.А ещё есть хороший принцип eat your own dogfood -- а я ни тех, ни тех сливных бачков на хозяйстве не держу. И денег от меня пока увидели только разработчики Sailfish (и ещё пообещал разработчику одного приложения под неё за полезные плюшки, если доберётся). Исчезающе мало по сравнению с GayStore и NsaPlay, разумеется -- но и богат не тот, у кого много денег, а кому достаточно.
Такие вот нерепрезентативные дела.
Предлагаешь пожалеть тебя, что работаешь на аудиторию ослов? Меняй аудиторию/работу. Это в первую очередь твой выбор.
>Предлагаешь пожалеть тебя, что работаешь на аудиторию ослов?Самая адекватная и платежеспособная аудитория. Про пожалеть и ослов - так тебе бы хотелось, но нет.
У нас довольно крупное приложение для IOS/Android. На IOS - 10 % пользователей, на андроиде - 90
Ну статистика примерно совпадает со статистикой мобильных ОС в мире. Под 90% Андроид и около 9 процентов иОС, остальное маргинальщина
Вендорлоченные платформы в пролёте, что вполне естественно.
Тебе надо - ты и сиди со своей проприетарщиной, а в этой теме тебе делать нечего
Если могильное приложение нормально работает в фоновом режиме надо эту штуку к zabbix прикрутить.
Тоже подумал об уведомлениях от заббикса.
Чем сабж лучше Centrifugo?
Спасибо за наводку
Вебсoкеты в 2019-м?
Вы серьёзнo?
Мoжет, всё же, MQTT?
MQTT - это более высокий уровень. Например, можно MQTT поверх WebSockets да еще и с TLS.
Offtop: https://symfony.com/blog/symfony-gets-real-time-push-capabil...Сервер написан на golang,
спецификация открытая: https://datatracker.ietf.org/doc/draft-dunglas-mercure/Проект молод, но уже набрал 1000 звёзд и официальная поддержка одного из самых крупных PHP сообществ сулит ему весьма радостные перспективы. Но не ограничивается только PHP.
Интересно, спасибо.
Не нужно, есть nginx-push-stream-module