Message Introduction

The IMLib SDK defines the RCMessage class for message transmission and management.

RCMessage Model

The RCMessage class encapsulates the following key data:

• Message transmission attributes: Sender userId, recipient userId, conversation type, etc.
• Message content body: Encapsulates the specific content carried by a message, divided into regular message content bodies and media message content bodies. For example, text message content (RCTextMessage) belongs to regular message content bodies, while image message content (RCImageMessage) belongs to media message content bodies. The type of message content body, often referred to as the message type, determines whether to use the interface for sending regular messages or media messages.

tip

The term "message" appearing in the documentation refers to messages that inherit from RCMessageContent (like text messages) or messages that inherit from RCMediaMessageContent (like image messages).

The table below describes key attributes of the RCMessage class. For a complete list of attributes, please refer to the API documentation.

The data structure of RCMessage is as follows:

Attribute	Type	Description
objectName	NSString	The identifier name of the message type, determined by the value obtained from the message body class method +getObjectName.
content	RCMessageContent	The specific content carried by the message, which must be a subclass object of RCMessageContent or RCMediaMessageContent, encapsulating the specific data fields of different message types. The IM service provides predefined message types and specifies cross-platform consistent message content body structures (see Message Type Overview), such as text, voice, images, GIFs, etc. You can also create custom message types by defining custom message content bodies.
conversationType	RCConversationType	Conversation type enumeration, such as one-to-one chat, group chat, chatroom, ultra group, system conversation, etc. Refer to Conversation Introduction.
senderUserId	NSString	The user ID of the message sender.
targetId	NSString	Conversation ID (or Target ID), used to identify the conversation counterpart. For one-to-one conversations, the counterpart user's ID is used as the Target ID. Therefore, the Target ID of all sent and received messages must be the counterpart user's ID. Note: The Target ID stored in the local message data for messages received by the local user is not the current user's ID but the user ID of the counterpart (the message sender). In group, chatroom, ultra group conversations, the Target ID is the corresponding group, chatroom, ultra group ID. For system conversations, since client users cannot reply to system conversation messages, no Target ID is needed.
channelId	NSString	Ultra group channel ID.
messageId	long	Message ID, the unique ID of the message in local storage (database index unique value).
messageUId	String	Message UID, globally unique under the same App Key. Only successfully sent messages have a unique ID.
messageDirection	RCMessageDirection	Message direction enumeration, divided into sent and received.
sentTime	long long	Message sending time. The sending time is the server's local time when the message arrives at the server from the sending client. Uses UNIX timestamp in milliseconds.
receivedTime	long long	Message receiving time. The receiving time is the client's local time when the message arrives at the receiving client. Uses UNIX timestamp in milliseconds.
sentStatus	RCSentStatus	Status of the sent message. Such as sending, sent successfully, failed to send, canceled sending.
receivedStatusInfo	RCReceivedStatusInfo	Status class of the received message, such as whether it has been read or downloaded. For details, see Message Receipt Status.
readReceiptInfo	RCReadReceiptInfo	Group chat message read receipt information. For details, refer to Group Chat Message Receipt.
canIncludeExpansion	BOOL	Whether message expansion is allowed. For details, refer to Message Expansion.
expansionDic	NSDictionary	Message expansion information. For details, refer to Message Expansion.
extra	NSString	Additional information of the message. This field is for local operations and will not be sent to the server. Distinguish this from RCMessage.content.extra, which will be sent to the counterpart along with the message.
isOffLine	BOOL	Whether it is an offline message. Only valid in the message receipt callback method. If the message is an offline message, the value is YES; otherwise, it is NO.
hasChanged	BOOL	Whether the message has been modified. Only supported for ultra groups.
needReceipt	BOOL	Message read receipt operation identifier. This attribute is supported starting from SDK version 5.20.0. For details, refer to Per-Message Read Receipt Function.
sentReceipt	BOOL	Whether the read receipt has been sent. This attribute is supported starting from SDK version 5.20.0. For details, refer to Per-Message Read Receipt Function.
directedUserIds	NSArray<NSString *>	Array of users receiving targeted messages.
disableUpdateLastMessage	BOOL	Whether to disable updating to the latest message in the conversation. Default is NO: update, YES: do not update.

RCMessageContent

The RCMessage class encapsulates the content attribute, representing the specific content carried by a message. The type of message content body must inherit from the following base classes:

• RCMessageContent - Regular message content body. For example, the built-in SDK message type text message content body (RCTextMessage) inherits from RCMessageContent.
• RCMediaMessageContent - Media message content body, inheriting from the MessageContent base class and adding media file processing logic on top of it. When sending and receiving messages, the SDK determines whether the message type is a media type message. If it is a media type, the upload or download media file process is triggered. For example, the built-in SDK message type image message content body (RCImageMessage) inherits from MediaMessageContent.

The IMLib SDK provides predefined, cross-platform consistent message content body structures (see Message Type Overview), such as text, voice, images, GIFs, etc. If you need to implement custom messages, you can inherit from RCMessageContent or RCMediaMessageContent to create custom message content bodies.

Message Storage Strategy

The client SDK and IM server control the message storage strategy in the client local database and server, as well as whether to count towards the client's unread message count and other attributes, through the message storage strategy (RCMessagePersistent). Message content bodies inheriting from RCMessageContent or RCMediaMessageContent all comply with the RCMessagePersistentCompatible protocol, setting the RCMessagePersistent attribute related to storage.

If sending built-in SDK message types, the RCMessagePersistent is automatically handled by the SDK by default, requiring no additional operations. For the storage strategy of built-in messages, see Message Type Overview.

If you need to create custom message types, note that custom messages must comply with the RCMessagePersistentCompatible protocol. For details, see Custom Message Types.