How to implement message delivery receipts notifications in your Android chat app

Introduction

Sendbird Chat is a rich and advanced API that unlike other solutions supports delivery receipts.

With delivery receipts, users can have complete confidence that their message has been delivered to their intended recipients. And you as the developer will now have more flexibility on what you choose to do once the message has been delivered. Whether that be as simple as displaying an icon to show the message was delivered, or as complex as handling additional events in-app upon the message being delivered. The availability of delivery receipts is a feature that enables you as the developer to continue providing a world-class chat experience for your users with little effort on your end.

In this tutorial, we will talk about the message lifecycle as it exists in Sendbird, and provide you with some background as to how to implement it into your chat.

What is the messaging lifecycle?

The messaging lifecycle simply put is the journey of a message, from the thoughts being typed into words, to the recipient reading the message themselves. Without delivery receipts, the messaging lifecycle from the perspective of the sender would have looked something like the following:

1. The sender types a message and sends it
2. The message is sent to the server (With built-in offline messaging to handle cases of poor to no connection)
3. The message is read by the recipient

While this did cover most bases there could be a lot of uncertainty between steps 2 and 3. Until the recipient actually checked that chat and marked the message as read, the sender would have no idea if the message was successfully received by the recipient or not. The sender would be left wondering if the reason they saw no response was as a result of poor connection, or simply the recipient hadn’t gotten around to checking their chat yet. All these worries vanish when the life-cycle looks like this:

1. The sender types a message and sends it
2. The message is sent to the server (With built-in offline messaging to handle cases of poor to no connection)
3. The message is delivered to the recipient’s device
4. The message is read by the recipient

With the introduction of that crucial step between the previous 2 and 3 the lifecycle now gives a complete picture. Whereas before the sender would have no idea if the receiver ever got the message until the read receipts were updated, now within moments the sender can confidently see it’s been delivered and go about their day.

Great, so now that we’ve talked about why delivery receipts are so crucial to completing the message lifecycle let’s go ahead and take a little more of a technical look at some of the features Sendbird offers and how easily they can be implemented into your app.

Step 1. Sender types a message

The first part of the message lifecycle is fairly straightforward. At this stage, there are a few features that we should highlight which will take the message lifecycle and make it a little more clear as to how it fits into your app. On the sender side, we have the send message functions. Below you can see how easy it is to send different types of messages.

Sendbird allows for 3 types of messages to be sent: user messages, or text messages, file messages, or binary file messages, and admin messages, or text messages sent by an Admin. With these three types of messages, you can send anything from a simple text message to funny videos and pictures to location messages. With features like Sendbird’s auto-thumbnail generation, sending these messages can be about as easy as it gets.

On the receiver side, a good chat experience provides the ability for a user to see when the sender is typing a message. Sendbird has you covered with event handlers that let you know when a user is typing. Typing indicators are an excellent way to provide a bit more of a natural conversation within chat.

Step 2. Message is sent

Okay, so now your sender has decided to press send and the message is off to be delivered… right? Unfortunately not always. There are numerous reasons why that message could fail to send, a chief reason I’m sure we can all sympathize with is poor to no connection. Thankfully Sendbird also has features for that. Right off the bat, we have a callback on the send function which will notify you if the message was unable to be delivered to the server.

Sendbird has gone a step further to offer the ability for an offline experience for you. Conventionally for creating an offline chat experience you would have to create a local database on the device which downloads messages/channels and keeps them in sync with the server. For things like edits to messages, or deletions of messages, you would have to make sure code was written to both take care of the data on the server, but also make sure local changes are propagated as well. Maintaining this can be tedious, time-consuming, and leave your application prone to numerous points of failure. With the SyncManager, Sendbird handles all of the issues mentioned above automatically. Displaying messages is easy as before, but the traditionally difficult parts of maintaining an offline experience are handled natively by Sendbird so all you have to do to maintain synchronization between the server and the local cache is call resumeSync() when the connection to the server is established.

When setting up the SyncManager, there is even the ability to specify a retry policy in the event the user has poor to no connection, so you as the developer do not have to worry about handling retries programmatically. This will give both you and your user the confidence to hit send and trust that connection or no connection, the message will get through when the connection is stable.

Step 3. Message is delivered

So we have talked a bit about how Sendbird makes sure the senders’ bases are covered, but what about the receiver? Thus far we’ve covered that the message went through to the Sendbird server, but how do I know if it was delivered to the recipient’s device? Thanks to the new delivery receipts feature, your users will now know immediately whether or not the receiver did indeed get the message. This is done by simply marking the message as delivered on the recipient’s side.

When this action is done, an event handler will fire on the sender’s side letting them know that the message reached the intended recipient’s device.

From here you have a wide range of options, you can simply display check marks indicating that the message was successfully delivered, or depending on your use case, you can implement some client side responses to a successful delivery.

Step 4. Message is read

So the message was typed, sent, delivered now what? The final stage of the message lifecycle is the recipient reading the message. Sendbird has had read receipts for some time now, this feature allows for the sender of the message to easily be able to see when their message was read by the recipient. On the receiver side, all you need to do is mark the channel as read.

When this is done, an event handler on the sender’s side will fire and update you with the timestamp of when the message was read.

From here the recipient can now become the sender and this lifecycle can start all over again.

Conclusion

That’s it! Congrats, you now know all you need to go and quickly build the messaging lifecycle notifications into your current workflow! With delivery receipts, Sendbird adds one more thing that makes it even easier for you to provide your customers with a modern and engaging chat experience.