A SBDMessageCollection
retrieves data from both the local cache and Sendbird server and lets you quickly create a chat view without missing any message-related updates. This page explains how to create a chat view using the collection and serves as a migration guide.
In local caching, the SBDMessageListParams
is used instead of SyncManager's MessageFilter
.
A SBDMessageListParams
instance will determine how to sort and list the retrieved messages. Then, specify the starting point of the message list in the chat view using the collection's builder.
Use the SBDMessageCollectionDelegate
to determine how the client app reacts to message-related events.
A new addition to local caching is the didDetectHugeGap:
. If more than 300 messages are missing in the local cache compared to the remote server, Sendbird Chat SDK determines that there is a huge gap. For more information, see Gap and synchronization.
The following table shows when to call each event handler.
Delegate | Called when |
---|---|
| - A new message is created as a real-time event. |
| - A message is deleted as a real-time event. |
| - A message is updated as a real-time event. |
| - The channel information that is included in the user's current chat view is updated as a real-time event. |
| - The current channel is deleted as a rea-time event. |
| - A huge gap is detected through Background sync. In this case, you need to dispose of the view and create a new |
SyncManager's didReceive:succeededMessages:
,didReceive:pendingMessages:
, and didReceive:failedMessages:
should be changed as shown in the code below.
SyncManager's didReceiveNewMessage:
which notifies the client app of new messages in a channel should also be changed as shown in the code below.
SyncManager's fetchInDirection
method retrieves messages from the local cache and delivers them to the SBSMMessageCollectionDelegate
. In local caching, the SBDMessageCollection
can retrieve and display messages through four new interfaces, hasPrevious
, hasNext
, loadPrevious
, and loadNext
.
Unlike the SBDGroupChannelCollection
, pagination works in both directions for messages because messages can be shown in either chronological or reverse chronological order depending on how you set the value of the startingPoint
.
Method | Description |
---|---|
| - Checks if there are more messages to load from the previous page. |
| - If |
| - Checks if there are more messages to load in the next page. |
| - If |
In a SBDMessageCollection
, the initialization is dictated by the SBDMessageCollectionInitPolicy
. The SBDMessageCollectionInitPolicy
determines how initialization deals with the message data retrieved from the local cache and API calls. Because we only support the cacheAndReplaceByApi
at this time, you should clear all messages in the local cache before adding messages from the remote server. Messages will first be retrieved from the cached list using cacheResultHandler:
. Next, the apiResultHandler:
calls the API result list which then replaces the cached message list with messages received from the API call.
A viewpoint is a timestamp option that sets the starting point of the current user's view. This viewpoint can be reset anytime by calling the resetViewpointTimestamp()
method. SyncManager's resetViewpointTimestamp
is used to reset the timestamp of the current message collection to another specified time. To reset a viewpoint timestamp in local caching, you should dispose of the current message collection and create a new one.
In local caching, the result of sending a message is handled internally through the SBDMessageCollectionDelegate
. First, pending messages are delivered to local caching's messageCollection(_:context:channel:addedMessages:)
. Whether the message succeeds or fails in sending, the result will be delivered to the messageCollection(_:context:channel:updatedMessages:)
. Thus, in local caching, it is not necessary to manually send the callbacks from the sendUserMessage()
and the sendFileMessage()
to the handleSendMessageResponse()
as in SyncManager.
Note: Don't add the pending, succeeded or failed message objects of the
sendMessage()
callback to your message list data source. This can cause duplicate messages in the chat view.
In local caching, the result of resending a message is handled internally through the SBSMMessageCollectionDelegate
. First, pending messages are delivered to local caching's messageCollection(_:context:channel:updatedMessages:)
. Whether the message has succeeded or failed in sending, the result will be delivered to the messageCollection(_:context:channel:updatedMessages:)
. Thus, in local caching, it is not necessary to manually send the callback from resendMessage()
to the handleSendMessageResponse()
as in SyncManager.
Note: Don't add the pending, succeeded or failed message objects of the
resendMessage()
callback to your message list data source. This can cause duplicate messages in the chat view.
To update a message using SyncManager, the message delivery status needs to be manually set through the messageCollection?.updateMessage(updatedMessage)
to let SyncManager know that a message has been successfully delivered. In local caching, however, updating messages is handled internally, and the result is delivered to the messageCollection(_:context:channel:updatedMessages:)
.
There are two cases for deleting a message:
Deleting a sent message.
In SyncManager, the process of delivering the status of message deletion through the deleteMessage()
is required. However, this process isn't needed in local caching.
Deleting a failed message.
The process is the same for both SyncManager and local caching where the failed message object is deleted explicitly from the local cache. In SyncManager, deleting a failed message is done through the deleteMessage()
. In local caching, the same can be done through the removeFailedMessages()
.
SyncManager's SBDMessageCollection
has a remove()
method that clears all the messages managed by the collection and stops the synchronization processes in the collection instance.
On the other hand, local caching uses the dispose()
method to clear the existing chat view. You should call this method when the current user leaves the channel or you need to create a new collection because a huge gap has been detected by the didDetectHugeGap:
.
SyncManager's messageCollection?.messageCount()
is used to count the number of succeeded messages in the collection. In local caching, it should be updated as shown in the code below.