Chat is an encapsulation of common chat requirements for a quick integratin with IM.
This document introduces to you the related concepts and considerations. For more details on the usage, please refer to the corresponding integration guide and API documentation when using it.
That are users, referring to the people participating in chat sessions, i.e, the service object of the application. Single chat can be initiated between users.
For applying a quick access to the existing user system, the Realtime Engine authenticates the user in a callback to complete the user sign-in. For the details on the authentication process, see User Authentication.
Every user is supposed to have a unique
userId as the unique identification of the user in the Chat system. This
userId usually belongs to the existing user system of the application, and it is bound to the current connection when calling the sign-in interface through the above user authentication process.
That are groups. A user can create groups and invite others to join, and the chats among group members are called group chat.
Every group has a unique
groupId, which is created by the Realtime Engine when calling the corresponding interfaces.
That are chats. Every chat, whether single chat or group chat, every participant, whether sending messages actively or receiving messages passively, a conversation will be automatically generated on the server from each perspective (if not existing before or deleted).
The conversations everyone sees has their own unread messages (
unreadMessageCount). When the counterpart is sending messages, no matter whether the user is online or not, this value will automatically increase. Usually the application needs to actively call the related interface to reset the value as 0 when users enter or leave the conversation interface.
Conversations can be deleted, which only takes effect to the action taker but not other users.
That are messages. Usually each SDK places the interface of sending messages in the conversation. The objects such as
conversation are probably the conversation histories loaded from server or created temporarily locally. When you send messages to one of them, the single chat user or group users the conversation correlated with will all receive the messages and a corresponding conversation will be generated.
Messages can be categorized as follows in line with the content.
Among which, graphic, audio and video messages are also called multimedia messages, and are sent through two steps:
In addition, every message can have an
extra field, which is the additional information used to implement the custom business logic of the application under the circumstances of the above message types not able to satisfy the application requirements.
Every message has a
messageId, and it increments independently in each conversation to make it easy for the developer to sort according to ID. The interfaces provided by each SDK for loading message history all need to offer
limit. Please see the usage below:
|-||-||-||latest 20 messages|
|11||-||-||20 messages from 11 (included), i.e., 11~30|
|11||-||50||50 messages from 11 (included), i.e., 11~60|
|10||40||-||20 messages from 10 (included) to 29 (included)||due to restriction by
|10||40||31||31 messages from 10 (included) to 40 (included)|
|-||40||-||20 messages from 21 (included) to 40 (included)|
|-||40||30||30 messages from 11 (included) to 40 (included)||Recommended! Get the latest 20 messages first, and then get in turn in this way|
To save traffic, each SDK will cache partial data locally so as to reduce unnecessary network transport:
endId. Only when the local cache doesn’t contain certain messages in this scope can those messages be retrieved from the server.
In case the cache has been enabled, the SDK can support the offline function, i.e., when the network is unavailable, the SDK supports the invocation of certain APIs. If the user has not yet signed in or signed out alreay, all the APIs are not available. If the user has signed in, different APIs will have different behaviors:
When initializing the
Engine, the following parameters can be configured:
supportOffline: whether to enable the offline function,
maxOfflineTime: maximum offline duration (sec), -1 indicating eternal, 30 days by default (compared with last online time). This parameter is valid only when