OR
Пуш с сервера в любом случае лучше, чем опрос сервера по таймеру
Size: a a a
2020 December 01
EA
Но мне идея про пуш и забирания ивентов не нравится если честно. Лучше он сначала заберет ивенты, а потом покажет пуш
Можешь делать сервер на сокетах, так тебе проще будет.
Создашь при не обходимости сервис фоновый, если прил закрытый может быть, а данные должны приходить.
Создашь при не обходимости сервис фоновый, если прил закрытый может быть, а данные должны приходить.
PS
Пуш с сервера в любом случае лучше, чем опрос сервера по таймеру
ой, хотелось бы не привязываться именно к пуш. Пуш(как мне кажется) служит не для коммуникации аплекухи с сервером, а именно для уведомления. Привязывать "забирать ивенты" к пушу - мне кажется не очень хорошая идея
PS
Можешь делать сервер на сокетах, так тебе проще будет.
Создашь при не обходимости сервис фоновый, если прил закрытый может быть, а данные должны приходить.
Создашь при не обходимости сервис фоновый, если прил закрытый может быть, а данные должны приходить.
вебсокеты постоянно висят как конекшены на сервере?
EA
Пока ты не закроешь соединение
OR
ой, хотелось бы не привязываться именно к пуш. Пуш(как мне кажется) служит не для коммуникации аплекухи с сервером, а именно для уведомления. Привязывать "забирать ивенты" к пушу - мне кажется не очень хорошая идея
Практически все мессенджеры так и работают - пуш их "будит", а потом они либо с сервера, либо с отправителя забирают данные.
Если без пуш, то сервер на сокетах и постоянный онлайн-канал держать
Если без пуш, то сервер на сокетах и постоянный онлайн-канал держать
OR
Но на большинстве смартфонов андроид либо усыпит приложение, либо закроет при нехватке памяти и тогда канал с сервером упадет до открытия/перезапуска.
OR
Пуш для того и придумали, что система "будит"/запускает приложение и уж дальше оно работает
OR
Как вариант - гибрид. Клиент держит канал с сервером и если клиент отвалился, то сервер его будит пушем.
OR
Тогда данные от отправителя через сервер или напрямую на получателя без ивентов.
OR
Но в этой схеме приложение активно фоном будет постоянно и не даст уснуть телефону.
И это скажется на расходе энергии.
И это скажется на расходе энергии.
PS
Практически все мессенджеры так и работают - пуш их "будит", а потом они либо с сервера, либо с отправителя забирают данные.
Если без пуш, то сервер на сокетах и постоянный онлайн-канал держать
Если без пуш, то сервер на сокетах и постоянный онлайн-канал держать
я о том же. Вебсокеты - это коннекты на сервере. Сразу вариант отпадает
OR
я о том же. Вебсокеты - это коннекты на сервере. Сразу вариант отпадает
Все зависит от задачи
PS
а вот привязка к пушам - мне кажется плохая идея, пусть даже все меседжеры так работают. Потому что когда прилетает пуш и юзер этот пуш открывает, то происходит задержка. Пока аплека постучится на сервер, пока подберет ивенты, пока она их разберет и обработает - происходит задержка
PS
Как вариант - гибрид. Клиент держит канал с сервером и если клиент отвалился, то сервер его будит пушем.
Усложнение. Долна быть какая-то простая реализация
PS
но вариант чекать ивент бокс по таймеру мне тоже не нравится. Это будет сервер нагружать
OR
а вот привязка к пушам - мне кажется плохая идея, пусть даже все меседжеры так работают. Потому что когда прилетает пуш и юзер этот пуш открывает, то происходит задержка. Пока аплека постучится на сервер, пока подберет ивенты, пока она их разберет и обработает - происходит задержка
Пуши заставляют систему будит приложение, а дальше оно реагирует как-то и это совсем не обязательно уведомление пользователя
OR
По пушу клиент может отдать серверу айпи, а сервер может их отдать отправителю для прямой связи
PS
Пуши заставляют систему будит приложение, а дальше оно реагирует как-то и это совсем не обязательно уведомление пользователя
а есть какая-то реализация пушей без уведомления юзера?
OR
а есть какая-то реализация пушей без уведомления юзера?
Не знаю, читать надо