My first initiative as a Merit employee was implementing push notifications on our React-Native mobile app. In fact, I was more than just a developer, I was the initiative owner. I organized the project, wrote a large portion of the code, and ultimately was responsible for seeing it through to completion.
When we began this initiative, we wanted to ensure that we respected the time of anyone who received a Merit push notification. We only send notifications based on important events, like receiving a new merit, and avoid periodically blasting annoying reminders that serve more as a distraction than anything else.
At Merit, we use a library for sending push notifications instead of fully implementing the functionality ourselves. We do this for several reasons.
First, a push notification library provides a unified system for implementing push notifications. A good library wraps the complicated, behind-the-scenes bits, and provides a reasonably simple API for sending and processing push notifications. You can query Apple or Google’s API directly to send notifications, because sometimes it’s nice to have.
Second, a good push notification library will support both Android and iOS. If you want to implement push notifications without a notification library, you will need separate implementations for Android and iOS. This is partially related to the first reason, creating a simple API. For simple notifications like those we send at Merit, you can act as if Android and iOS devices are identical. (Though be sure to test both!)
Once we settled on using a push notification library, there was the small matter of deciding which one to use. For us, this was a fairly simple decision as our app is already built using Expo. Expo’s push notification library is sufficient for our use cases and using it meant one less dependency in our application.
If you are implementing push notifications using Expo’s library, you should read their documentation completely (you can find it here). If you go to the ‘Sending Notification’ section of Expo docs, you will see that they’ve built libraries for sending notifications in a variety of languages. At Merit, we use Scala to send push notifications and are releasing a Scala method of sending a push notification with Expo as an open-source library!
There are two main requests you have to send to Expo to properly send a push notification:
Our library implements both of these.
Once you have an Expo push token, combine that token with your message and send it to Expo. From there, Expo will route it to wherever it needs to go. In response, Expo will give you a push ticket. This ticket is how you track the status of your push notification, and you will need it to check the result of sending your notification.
Our library will send a notification and return the ticket, however, you need to persist the ticket for later use.
Here is the code we used. If you are comfortable with Scala with Cats then it may interest you. Otherwise, check out what other developers have done in other libraries for sending push notifications. You saw the example code linked in Expo’s documentation, right?
Use a gist here for consistency’s sake, though mention this code is in open source repo.
The next step is to ensure that your notifications are being properly sent and received. Periodically take all your push tickets and submit them to Expo. Expo will take your push tickets and return push receipts. These push receipts may contain errors from Expo, so ensure that you take these errors and perform the appropriate remedy.
Stay tuned for part two, where we discuss front-end changes and tricky bits you’ll want to consider when adding push notifications to your app.