Уведомления для андроид приложения
Второй месяц занимаюсь выполнением тестового проекта, а именно простейшего мессенджера.
Что сделано:
- написана серверная часть на C# (Web-Api-Asp.Net-Core) (в Visual Studio) - API-интерфейс. Методы сервиса принимают, обрабатывают, сохраняют в БД (SQL Server), считывают с БД, упаковывают и отправляют на клиент данные по потребности запросов.
- Написано на JAVA (в Android Studio) простое приложение, коммуницирующее с выше указанным API-сервисом.
Мессенджер прекрасно работает (как я верил в это) и я с радостью наблюдал плоды своей работы: пользователи реально общались между собой в режиме реального времени.
Но препод не принял мою работу и дал срок максимум две недели переделать систему.
Суть проблемы: основная проблема - высоконагружаемость приложения из-за частого пинга сервера (раз в секунду клиент опрашивает вебсервис на наличие поступивших новых сообщений). Дополнительная проблема - неполучение уведомлений с сервера в случае когда пользователь вышел из приложения.
Промониторив возможные варианты решения данных проблем наткнулся на такую систему как ФаерБейз.
Но не могу до конца понять механизм ее работы. Если я правильно понимаю, то суть сводится к тому, что мой сервер (API-сервис) по мере надобности отправляет на сервер ФаерБейз определенные пакеты данных (и они там где-то складываются, или не складываются) и уже сервер ФаерБейз отправляет (рассылает) эти данные по клиентским приложениям.
Клиент, получив подобное уведомление, кликает на него и переходит в соответствующую Активити приложения и далее уже само приложение отправляет запрос на мой API-сервис для получения всех полных новых актуальных данных.
Правильно ли я понимаю суть замысла сервиса ФаерБейз, или я путаю?
Прошу опытных помочь поскольку времени для реализации мало, а начинать разработку с неправильным пониманием сути решения не хочу.
Заранее спасибо за всякую помощь.
Ответы (1 шт):
Вот к какому понимаю процесса взаимодействия абонентов-клиентов через общение с сервером я пришел (поправьте, если понимание неверное):
Первый абонент отправляет сообщение на сервер. Это делается через установленное веб-сокет соединение (или другой транспорт, поддерживаемый SignalR), используя API, предоставляемое SignalR.
Сервер принимает сообщение. После получения сообщения сервер обрабатывает его как нам требуется (упаковка и отправка в хранилище, у меня это БД СКЛ).
Сервер отправляет сообщение второму абоненту (склоняюсь, что этот 3-й пункт может предшествовать 2-му). Используя подсказанный Вами
SignalR, сервер может отправить сообщение определенным клиентам (например, другому абоненту чата, или другим абонентам чата) или группам клиентов. Это делается асинхронно и, как я наблюдаю, практически мгновенно, поэтому второй абонент получает сообщение с минимальной задержкой.Запись сообщения в базу данных. Для сохранения истории сообщений сервер может асинхронно записывать сообщения в базу данных. Это обеспечивает постоянство данных и позволяет абонентам восстановить историю сообщений при повторном подключении или просмотре истории. Смотрю в сторону асинхронности только по причине сохранения скорости доставки нового сообщения другому абоненту (абонентам) поскольку я так понимаю, на уровне взаимодействия с БД могут быть значительные потери времени. А если так, то теряется ощущение присутствия в реальном времени. А за это отсутствие ощущения я реально схлопочу неуд по предмету.
Процесс повторяется в обратном направлении, если второй абонент отправляет ответное сообщение первому абоненту.
Я так понимаю вместе с текстом сообщения следует передавать userId и chatId.
Если так, тогда на стороне сервера я, как мне кажется, мог бы отфильтровывать для определенного абонента только те сообщения, которые соотносятся с соответствующим чатом, проверяя на совпадение chatId.
Но пока я не "въезжаю" как это возможно реализовать на этапе ДО внесения сообщения в БД.
Если же вариант: сперва занести в БД новое сообщение, а потом выбрать новые сообщения для абонента на другом конце "связи" по значению chatId, тогда это понятно как делается.