Architecture
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:
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.
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. TCCTeleClient is used as an abstraction of the FFI-methods and to keep an active handle to the current FFIClient. TCCTeleClient>>send is called by the core or any handlers to send calls to TDLib.
For separation of concerns we split different parts of the logic into different Handlers, which are maintained by TCCCore. AuthHandler is used to send and handle events while authenticating. We use the ChatHandler for message sending and chats loading.
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.
Furthermore TCCNullChat represents a chat that is behind every other chat and TCCNullMessage is used in every chat to mark the last message, when there are no messages loaded yet. This makes working with cases such as empty chats easier and serves as an abstraction behind some parameter specifications from TDLib.
Whenever you create an new instance of TCUTelegram a TCUAuthentication is created to log you in. After you are logged in, or if your account has been logged in before the window closes and an instance of TCUMain is created, which is what you'll see most of the time. 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 chats which shifts on scrolling.
Notification are created directly in TCUMain when new messages arrive.