SDK architecture

An overview of the edna Chat Center Android SDK architecture from an integrator's perspective: module structure, the asynchronous connection sequence, and the threading model. This page covers only the public contract and the facts you need to consider when embedding the SDK. The names of internal components and the order of calls between them are not documented: they may change without notice in minor releases.

Module structure

The SDK has a modular design with two layers: ChatCenterCore (the core) and ChatCenterUI (the user interface). The integrating app primarily interacts with ChatCenterUI, which delegates logic to the core.

Module	Responsibility
ChatCenterUI	Chat fragments/activities, UI event handling, displaying messages, attachments, notifications. Depends on ChatCenterCore.
ChatCenterCore	Network interaction (REST + WebSocket), local storage, parsing, authorization, state management. Does not depend on the UI module.

The SDK configuration is described by ChatConfig (which extends ChatConfigCore), ChatTransportConfig, and ChatNetworkConfig — full field reference is in Settings → ChatConfig. The full list of ChatCenterUI methods (init, authorize, logout, getChatFragment, send, …) is in Methods → Authorization and Methods → Messages.

---

Connection sequence

When chatCenterUI.authorize(client, auth) is called, the SDK performs several asynchronous steps in sequence:

1. User authentication on the server.
2. Loading the server-side chat widget configuration.
3. Device registration for push notifications.
4. Sending user data.
5. Receiving server confirmation and loading message history.

Track chat readiness via the public callbacks: ChatCenterUIListener (see Methods → Delegates) and ChatUpdateProcessor flow events (advanced scenarios). Network errors at any stage are delivered to networkErrorReceived — see Errors.

After authorize(...), do not access the chat screen immediately expecting ready data: the SDK is still performing the handshake, and ChatFragment will display a loading state until the first server response. Do not retry authorize(...) with the same parameters as a workaround — the SDK does not perform an early-return and re-establishes the internal connection. Add a guard on the app side if repeated calls are possible (e.g., on network restoration) — see Known limitations → WebSocket disconnect behavior.

Internal connection state is not part of the public API

The SDK tracks the states of the listed stages internally on its own enum, but there is no public way to subscribe to its current value — neither through ChatCenterUI/ChatCenterCore, nor through ChatCenterUIListener, nor through ChatUpdateProcessor. Do not rely on specific values of this internal state in your app code — use the callbacks listed above.

---

Threading model

The SDK uses a multithreaded model with responsibilities split across threads. This section lists the publicly observable threading guarantees — what you can and cannot rely on when working with SDK callbacks.

Thread	Operations
Main (UI) thread	Callbacks unreadMessageCountChanged and exceptionReceived, UI component updates, user action handling.
Background threads	Network requests (REST API), WebSocket connection, JSON parsing, local DB operations, push notification handling, the networkErrorReceived callback (see below).

networkErrorReceived does not guarantee the main thread

The callback ChatCenterUIListener.networkErrorReceived(error) in the current SDK implementation may be delivered from a background thread — most call sites originate from OkHttp WebSocket, @WorkerThread methods, and Dispatchers.IO. A portion of Retrofit-enqueue() callbacks arrive on main, but that is an implementation detail you cannot rely on. Wrap any UI operations inside this callback in runOnUiThread { ... } or Handler(Looper.getMainLooper()).post { ... } — otherwise you will get CalledFromWrongThreadException.

The unreadMessageCountChanged and exceptionReceived methods are called on the main thread; for urlClicked, the thread depends on the call site in the UI. The full thread breakdown for all four ChatCenterUIListener callbacks is in Known limitations → ChatUpdateProcessor coroutine scopes.

ChatCenterUI call thread

ChatCenterUI methods (send(), authorize(), logout(), etc.) must be called only from the main thread. If you need to initiate the call from a background thread, wrap it via runOnUiThread { ... } or your own call serialization on the app side.

See also Known limitations → Race condition on parallel ChatCenterUI calls.

---

Related sections

• Application lifecycle — where and in what order to call init, authorize, logout.
• Methods → Delegates — ChatCenterUIListener, callback threading, MessageStatus.
• Methods → Errors — handling networkErrorReceived and retry strategies.
• Settings → ChatConfig — ChatConfig / ChatConfigCore fields, PendingIntentCreator, deprecated parameters.
• Push notifications — FCM/HMS integration, handleFCMMessage.
• Known limitations — parameters overridden by the server, behavioral notes.