Перейти к основному содержимому
Версия: 5.21.0

Архитектура SDK

Обзор архитектуры edna Chat Center Android SDK с точки зрения интегратора: модульная структура, асинхронная последовательность подключения и модель потоков. На этой странице — только публичный контракт и факты, которые нужно учесть при встраивании SDK в приложение. Имена внутренних компонентов и порядок вызовов между ними не документируются: они могут меняться без предупреждения в минорных версиях.

Структура модулей​

SDK построен по модульному принципу и состоит из двух слоёв: ChatCenterCore (ядро) и ChatCenterUI (пользовательский интерфейс). Приложение-интегратор взаимодействует преимущественно с ChatCenterUI, который делегирует логику ядру.

МодульОтветственность
ChatCenterUIФрагменты/Activity чата, обработка UI-событий, отображение сообщений, вложений, уведомлений. Зависит от ChatCenterCore.
ChatCenterCoreСетевое взаимодействие (REST + WebSocket), локальное хранение, парсинг, авторизация, управление состоянием. Не зависит от UI-модуля.

Конфигурация SDK описывается классами ChatConfig (расширяет ChatConfigCore), ChatTransportConfig и ChatNetworkConfig — полное описание полей в разделе Настройки → ChatConfig. Полный список методов ChatCenterUI (init, authorize, logout, getChatFragment, send, …) — в Методах → Авторизация и Методах → Сообщения.

Последовательность подключения​

При вызове chatCenterUI.authorize(client, auth) SDK последовательно выполняет несколько асинхронных этапов:

  1. Аутентификация пользователя на сервере.
  2. Загрузка серверной конфигурации виджета чата.
  3. Регистрация устройства для push-уведомлений.
  4. Отправка данных пользователя.
  5. Получение подтверждения от сервера и загрузка истории сообщений.

Готовность чата к работе отслеживайте через публичные callback-и: ChatCenterUIListener (см. Методы → Делегаты) и flow-события ChatUpdateProcessor (продвинутые сценарии). Сетевые ошибки на любом из этапов приходят в networkErrorReceived — см. Errors.

После authorize(...) нельзя сразу обращаться к экрану чата, ожидая готовые данные: SDK ещё выполняет хендшейк, и ChatFragment будет отображать состояние загрузки до получения первого ответа сервера. Не повторяйте вызов authorize(...) с теми же параметрами как ретрай — SDK не делает early-return и переустанавливает внутреннее соединение. Добавьте guard на стороне приложения, если возможны повторные вызовы (например, при восстановлении сети) — см. Известные ограничения → Поведение при разрыве WebSocket-соединения.

Внутреннее состояние подключения — не часть публичного API

Внутри SDK состояния перечисленных этапов отслеживаются на собственном enum-е, но публичного способа подписаться на текущее значение нет: ни через ChatCenterUI/ChatCenterCore, ни через ChatCenterUIListener, ни через ChatUpdateProcessor. Не закладывайтесь на конкретные значения этого внутреннего состояния в коде приложения — используйте перечисленные выше callback-и.

Модель потоков​

SDK использует многопоточную модель с разделением ответственности между потоками. Эта секция перечисляет публично наблюдаемые threading-гарантии — на что можно и нельзя полагаться при работе с callback-ами SDK.

ПотокОперации
Main (UI) threadCallback-методы unreadMessageCountChanged и exceptionReceived, обновление UI-компонентов, обработка пользовательских действий.
Background threadsСетевые запросы (REST API), WebSocket-соединение, парсинг JSON, операции с локальной БД, обработка push-уведомлений, callback networkErrorReceived (см. ниже).
networkErrorReceived не гарантирует main thread

Callback ChatCenterUIListener.networkErrorReceived(error) в текущей реализации SDK может прийти с фонового потока — большая часть call-sites идёт из OkHttp WebSocket, @WorkerThread-методов и Dispatchers.IO. Часть Retrofit-enqueue()-callback'ов приходит на main, но это деталь реализации, на которую полагаться нельзя. Любые операции с UI внутри этого callback оборачивайте в runOnUiThread { ... } или Handler(Looper.getMainLooper()).post { ... } — иначе словите CalledFromWrongThreadException.

Методы unreadMessageCountChanged и exceptionReceived вызываются на главном потоке; для urlClicked поток зависит от точки вызова в UI. Полный разбор call-sites для всех четырёх callback-ов ChatCenterUIListener приведён в Известных ограничениях → ChatUpdateProcessor coroutine scopes.

Поток вызова ChatCenterUI

Методы ChatCenterUI (send(), authorize(), logout() и т. п.) необходимо вызывать только с главного потока. Если требуется инициировать вызов из фонового потока — оборачивайте через runOnUiThread { ... } или собственную сериализацию вызовов на стороне приложения.

См. также Известные ограничения → Гонка при параллельном вызове методов ChatCenterUI.

Связанные разделы​

Последнее обновление