Send a Message
Last updated
Last updated
Messaging is an essential component of any chat application, and the SDK provides robust messaging features. The SDK optimizes the messaging flow for users by instantly displaying sent messages, even before they have been delivered to the server. To ensure the user's smooth messaging experience, the SDK provides the syncState property in the message model to monitor the message delivery status.
Amity supports the sending and receiving of five types of messages:
SDK (Android & iOS) now supports resynchronization of message if the internet connection is not available or interrupted at the time the user sends a message. To support resynchronization, we enhanced the internal architecture on how the messages are queued, processed and synced with server.
SDK (Typescript) supports message synchronization starting from version 6.27.0. However, the synchronization process is not fully supported, and we cannot guarantee the order of message creation or retry and delete for failed message creations.
When you create a message, SDK first creates the message locally. This locally created message will be reflected immediately in the related live collection that user is observing at the moment. Then the SDK starts syncing this message with server. User can check the syncState property of the message model inside live collection to reflect the current state of the message.
Once a message is created locally, SDK adds the message to the queue and starts the process of syncing this message with server. After the message is synced with server, the syncState of the message changes to synced. Here is the table showing various state of the message and its corresponding syncState value per platforms.
| Message State | iOS | Android | Typescript |
|---|---|---|---|
When message is created locally and waiting in queue for syncing to server | syncing | created | syncing |
When message is being synced to server | syncing | syncing | syncing |
When message attachment is being uploaded to server | syncing | uploading | syncing |
When message is synced successfully with the server | synced | synced | synced |
When message syncing failed | error | error | error |
The messages are synced in the order they get added to the queue in FIFO (First In First Out) order. SDK will maintain causal ordering of the message of similar types.
SDK maintains causal ordering for similar type of messages i.e (Text, Custom) & (Image/File/Audio/Video). Let’s look at the example to understand this:
If user creates messages in this order from left to right: [Text1 → Image1 → Image2 → Text2 → Text3 → Image3]
The ordering of text messages are maintained i.e Text 2 will be synced after Text 1 & so on
[Text1 → Text2 → Text3]
The ordering of Media messages are respected i.e Image2 will be synced after Image 1 and so on.
[Image1 → Image2 → Image3]
The ordering of all messages mixed might not be respected. Ex: If image1 takes longer time to upload, the ordering can be:
[Text1 → Text2 → Text3 → Image1 → Image2 → Image3]
SDK automatically determines the internet connection availability on user device and waits for the stable connection before sending the request to sync with server. Once the connection is available, SDK syncs the message with the server maintaining the causal ordering as described above.
If the network connection is interrupted during the request or server returns error for the request, depending upon the interruption state & error returned, SDK will automatically retry syncing the message after some interval (~ 5 seconds). SDK will retry syncing up to maximum 3 times and if the message still cannot be synced, SDK will mark the message as failed and notify the user through callback of createMessage api. The syncState of the message would change to failed / error.
The message syncing can fail for many reasons. User should handle the error thrown from create message api and decide what to do for failed messages. Once the status of the message is failed, SDK will not attempt to retry syncing that message anymore. The failed messages will not be automatically removed from the live collection. It’s up to the user to decide if they should resend the same message or delete the failed message so that it disappears from the live collection. The syncState of the failed message would be failed / error.
You can use existing softDeleteMessage() method in AmityMessageRepository class to delete specific failed message.
If you do not care about any failed messages, SDK also provides deleteFailedMessages() method in AmityMessageRepository class to allow deletion of all failed messages.
This message syncing process is only maintained per active session per device. If user logs out or if user current session is destroyed, all the active syncing process is terminated.
When the SDK is initialized again (i.e client instance is initialized), all the messages which were in syncing state from the previous session would be changed to failed state. User can choose to delete particular failed message (using softDeleteMessage() method) or delete all failed messages (using deleteAllFailedMessages() method).