Более того в представленном списке нет ни одного цвета, который бы слился с бэкграудом...

А, ну тогда нет проблем. Просто нужно понимать, что при установке соединения с Rabbit открывается сокет и это не надёжно для мобильных устройств. Так же мобильных устройств, если их много, начнут насиловать Rabbit реконектами, да и количество соединений тоже ограничено.

А если будет 200. 😕. Что лучше тогда. Google Firebase. SignalR

Все привет! Ребят, прошу помощи разобраться, может ни туда копаю. Как ранее писал, есть XF проект,Одна из функций которого запустить по требованию пользователя таймер с обратным отчетом. Т.е. пользователь выставляет время, например 5 минут - запускает - и приложение должно показывать обратный отчет: 04:45 - 04:40 - ... по окончанию уведомить пользователя о том, что время вышло. С локальными уведомлениями проблем нет, всё ок. Но с обратным отчетом проблема. При засыпании, блокировки, переключении на другое приложение обратный отчет приостанавливается, когда возвращаюсь в приложение продолжает отчет, так может быть очень долго.
Вторая функция, это напомнить пользователю о задаче в конкретное время.
Что сделал: В нативной части андроида реализовал Service, в нем OnStartCommand сервиса происходит запуск действия runnable и создания/ регистрация службы в качестве переднего плана, для тех устройств у которых Андроид выше Орео или ниже.
Из XF проекта запуск обратного отчета реализовано так: view - VM-MessagingCenter

Сделал мини логирование о том как работает часть с действием runnable, если смотреть на скрин, то снизу видно, что сервис запущен, 30 сек работает норм, затем "заснул" проснулся когда приложение раскрыл из фона (4:46 на скрине). Как сделать так, чтобы таймер работал и приложение не "засыпало", таймер не замирал ?

при этом на переднем плане служба висит. перебирать дальше ? jobService, FCM ? или может XF сторона "засыпает"

Я Workmanager юзаю

200 тоже нормально

Главное чтобы это число не росло экспоненциально

по стандарту, если вы не правили настройки, то один сервер/инстанс Rabbit держит 128 соединений

Те условно под каждые новые N(default 128) человек, которые одновременно пользуются приложением, нужно поднимать еще один Rabbit

Так что напрямую ходить - не самый хороший вариант, хоть технически с этим проблем и нет

Стоит подумать над архитектурой вашего взаимодействия с нотификациями и тд

Вебсокеты там организовать....

Ну, например на них. Или использовать какие-либо обертки над ними по выбору.

Можно использовать тот же SignalR

Или так)

который в StandAlone версии уже может обслужить гораздо больше людей, чем один Rabbit