Skip to main content
Chat SDK v4 2x

Swift, Kotlin, and TypeScript SDKs

Build in-app chat, calls, and live streaming

On This Page

A better way to test push notifications

Gunou Park profile pic
Gunou Park
Platform Server Engineer
  • Tutorial Type: Getting started
  • Reading Time: 4 min
  • Building Time: N/A
Chat SDK v4 2x

Swift, Kotlin, and TypeScript SDKs

Build in-app chat, calls, and live streaming

Chat SDK v4 2x

Swift, Kotlin, and TypeScript SDKs

Build in-app chat, calls, and live streaming

On This Page

Introduction

Push notifications are important. Especially in chat. The timeliness of the notifications could be the decider for how engaging a conversation ends up being. Check out our handy guide to understand why push notifications are important and how they can be used. The guide also contains some tips for sending relevant and useful push notifications.

Sendbird provides chat as an integrated part of our customers’ services. As our customers range over various industries, the use cases also vary from simple 1-on-1 based chatting to large group chats, to marketing push notifications. To streamline the process of keeping the users engaged through push notifications, Sendbird now provides the push notification testing tool on the dashboard. Read the launch announcement here.

Push notifications with Sendbird

The end-user experience for push may appear quite simple. A user sends a message, and the recipient receives the push – if intended.

For this seemingly simple procedure, there are multiple components involved. Customers must allow Sendbird to send push notifications on behalf of their applications. Users must register their device with Sendbird through customer applications. Once the configuration is completed, Sendbird will request the push providers – i.e. Firebase Cloud Messaging for Android devices, Apple Push Notification service for iOS devices – to send the push notification to respective devices.

In the whole stream of components to get through, Sendbird’s messaging service allows various configurations and conditions for push notifications such that our customers can engineer the best user experience for their users. Push preferences are available at the application level, user level, and at channel level.

On top of the flexibility with push notifications, reliability and scalability must be guaranteed. Sendbird’s architecture is designed to maintain its availability, accounting for the possible unavailability of the push providers and the fluctuating need for push notifications due to the huge spectrum of use cases. The main messaging service takes care of the messages and decisions on to whom push notifications should be sent, and it delegates the job to a push-dedicated microservice that operates serverlessly and asynchronously.

Push notification flow chart

Struggling with misconfigurations

As customers try out Sendbird and wire up push notifications for their applications, it is possible that there is a misconfiguration – whether it be device registration or provider certificate registration.

This is where things can get tricky and frustrating. Due to the nature of having multiple third-party components involved and the complex control flow, it is not easy to identify the causes when there is a misconfiguration for push notifications. If a push notification does not arrive when it is expected, our customer must wonder: are the user-level settings the problem, or is the device not hooked up with Sendbird? Or is there a user-device mismatch?

Such unresolved uncertainty can not only slow down the integration of Sendbird’s chat as a whole but also results in a lack of confidence in shipping the final integration to the end users. To clear out the uncertainties and provide confidence, Sendbird now provides the push notification testing tool.

Fire away with Sendbird

The push notification testing tool focuses on three major things. One, giving direct feedback on the current push-related set-up, with the user, device, and push provider. Two, delivering the error codes from push providers when push requests are rejected from the push providers. Three, giving the device the intended “ding” on the device, by bypassing all the user-level and channel-level push preferences to confirm there are no issues with the set-up.

The tool required some new data and control pathways dedicated to testing. Since the architecture separates push from the main service, there was a need to trace the responses from asynchronous push requests. So a separate, trackable form of datastore that holds the responses from the push providers was introduced for this purpose. Then, to chase after for the result, the tool polls for the result of asynchronous push in a controlled manner. Combined with the bypass for push preferences, the customer can easily figure out the errors for the misconfiguration through the testing tool on the Sendbird dashboard.

Once all the errors are dusted, there will be a “ding” to the device and the push integration is ready to go!