Architecture

Architecture Overview

We aimed a MVVM architecture, requiring that there are no references from models to the view layer. Take a look at our detailed architecture model:

You can find the diagram for editing and updating here: DrawIO

Relation between Core and UI

We focused on the separation of UI and core, making the core reusable for a different interface. Notice that there are only very few links between UI-Classes and classes from the Core-package. Those relations are implemented by using an Observer-Pattern via when:send:to:. The core triggers messages whenever events happen, that a user might find interesting. A UI subscribes to the messages it wants to handle and implements the displaying logic.

OS-dependent Classes

The only classes that depend on a specific operating system are the three Subclasses of TCCFFIClient: TCCLinuxClient, TCCWindowsClient and TCCMacClient. The FFIClient can be used to generate a fitting subclass. TCCTdlibClient is used as an abstraction of the FFI-methods and to keep an active handle to the current FFIClient. TCCTdlibClient>>send is called by the core or any handlers to send calls to TDLib.

Handlers

For separation of concerns we split different parts of the logic into different Handlers, which are maintained by TCCCore. AuthenticationHandler is used to send and handle events while authenticating. We use the ChatsHandler for message sending and chats loading.

Data Classes

Another important part of our architecture are the data classes which are used as an abstraction to JSON objects. It stores received events in a TCCEvent and for sending calls an instance of TCCRequest is created. To store the most important objects of a messenger, we use TCCChat and TCCMessage data classes, which store all relevant attributes we currently support. These make dealing with chats and messages a lot easier especially the possibility to construct them directly from TDLib events. Chats are maintained in a SortedCollection-Subclass TCCChats, which keeps all chats in the order they are displayed. This collection triggers events whenever it changes and is thereby good object to subscribe in the UI.

UI-Architecture

Whenever you create an new instance of TCUTelegram a TCUAuthentication is created to log you in. After you have logged in, or if your account has been logged in before, the window closes and an instance of TCUMain will be created, which is the main Telegram window. It comes with a TCUHeaderBar as well as a TCUChatsList and a TCUChatWindow. The chats list subscribes to events from TCCChats and redraws whenever the order of the chats changes. The chats window consists of a TCUChatMessageList which displays single messages in a chat (messages are stored in a collection in the chat data class in order). It always shows a fixed window of the messages in a chat, which shifts on scrolling.

Notification are created directly in TCUMain when new messages arrive.

Dynamic loading of data

Every data object that has to dynamically request data has to know the running TCCCore as every event gets sent and received through it. The data object can benefit from other core objects that might already implement how to request the desired data.

Here are some considerations we had when deciding for this solution.

Option	Pro	Con
Data objects operate on the core directly	core does not know much and just sends out the requests corresponds to OOP	every data object knows the core
Core requests desired data for every data object on its own	data objects don't have to know core	core has to know very much
Core passes event to the corresponding handler	core does not know much data objects don't know much	UI has to implement logic for loading data