How to implement Messaging Lifecycle Notifications in your chat application

Alex Preston Solutions Engineer

Get Started!

Sign up for a full-featured 30 day free trial. No credit card required.

Free Trial

Earlier this month we released Delivery Receipts! So what does that mean for you and your chat implementation? 

Your users now will 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 release of Delivery Receipts is another feature that enables you as the developer to continue providing a world-class chat experience for your users with little effort on your end.

What this also means, is that with the release of Delivery Receipts, Sendbird has completed you and your user’s visibility into the entire messaging lifecycle. In this blog, we will talk a bit about the message lifecycle as it exists in Sendbird, and provide you with some background as to how it can be implemented fully 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. Prior to Delivery Receipts, the messaging lifecycle in Sendbird from the perspective of the sender would have looked something like the following:

  1. Sender types a message and sends it
  2. Message is sent to the server (With built in offline messaging to handle cases of poor to no connection)
  3. 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 are in the past as now the life-cycle looks a little more like this:

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

With the introduction of that crucial step between the previous 2 and 3 the lifecycle now takes on a completed 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 its been delivered and go about their day.

Messaging Lifecycle Notifications

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.

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: UserMessage, or text messages, FileMessages, or binary file messages, and AdminMessages, 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 might be to provide 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.

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 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.

3. Message 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 Sendbird, but how do I know if it was delivered to the receiver’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.

4. Message 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.

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