Registering for Notifications on Android
We are no longer allowing customers to onboard to Notify. We intend to deprecate the Notify product on April 25, 2024. Learn more in our Notify API End of Life Notice. We prepared this Transition Guide to assist in supporting your push notification use cases.
Ready to send your first notification? We'll get you registered so you can start sending notifications faster than a collision-free hash table lookup (OK, maybe not that fast).
A Notifications application involves two components:
- A client (Android) app that registers for and receives notifications
- A server app that creates bindings and sends notifications
The aim of this guide is to show you how to store the app's unique address in Notify by creating a Binding so that later we can send notifications to it. There are two cases when you would need to update the Binding in Notify:
- when the user logs in for the first time or with a new Identity
- when FCM changes the address of the app.
As both acquiring the address of the app and creating a binding may take a bit, it is best to implement registration in a dedicated service (e.g., RegistrationIntentService) and fire it in both scenarios. Let's start with the first scenario, logging a new user in and then add support for changing addresses.
When a user logs in, you want to capture the Identity and fire the RegistrationIntentService passing the new Identity as an Extra. Let's take a look at then how this RegistrationIntentService works.
First, the RegistrationIntentService needs to acquire the address of the app, the registration token. This is done by invoking the FirebaseInstanceId.getInstance().getToken(); method.
Next, we need to get the Identity from the extra and create a Binding in Twilio. A “Binding” represents a unique app installation that can receive a notification. It associates a registration token (that we just acquired) with an Identity (from the Intent Extra). You can use the Identity to send notifications to a specific user (Identity). (More on that later.)
The app should send a request to the server containing the registration token, Identity, and BindingType. The server then will use this information to create the Binding via the Twilio API. We add this indirection to avoid exposing our Twilio credentials in the Android app.
We use retrofit2 to make this request, but you can use any HTTP client. Our mini-API to communicate with our server is defined in the BindingResource, Binding and CreateBindingResponse* classes. The BindingResource interface defines the signature of our simple API.
The Binding class is a simple Plain Old Java Object (POJO) that the retrofit2 API will translate to JSON for us. It wraps the parameters we need to send to the server.
The CreateBindingResponse is another POJO to translate the server's JSON response including the generated endpoint identifier and a message in case something went wrong.
We are almost finished with the Android app. Remember that there was another scenario when we wanted to create a Binding: when FCM changed the registration token. To implement this, we will need to two simple steps:
- Register a service that listens to the token update events from FCM
- Implement that service
To register the service, we'll add an intent-filter to declare the capabilities of our service, the MyInstanceIDService.
Then we can implement this very simple service. All it does is, it invokes our RegistrationIntentService to create a new Binding.
*** MyInstanceIdService SAMPLE GOES HERE **
You may wonder, how can we just keep creating Bindings without ever deleting any? The Notify API's deduplication feature allows this. It deletes previous Bindings in the same Notify Service that have the same Address (registration token) or Endpoint. Endpoint is an auto-generated unique identifier that we receive from the Notify service. Notice how our SendRegistrationToServer method stores this Endpoint in the shared preferences and reuses it in subsequent create Binding requests ensuring that Bindings are not duplicated even when the registration token changes.
Server
Now that we have our Android app ready, let's turn our attention to the server that interacts with the Notify API.
In our server app, we’ll receive the POST request. It will contain the following four parameters.
| name | description |
|---|---|
| Identity | The Identity to which this Binding belongs. Identity is defined by your application and can have multiple endpoints. |
| Endpoint | The identifier of the device to which this registration belongs. Endpoints are also defined by your application. |
| BindingType | The type of the Binding determining the transport technology to use. |
| Address | The address obtained from the vendor. For APNS it is the device token. For FCM, it is the registration token. |
Do not use Personally Identifiable Information for Identity
Notify uses Identity as a unique identifier of a user. You should not use directly identifying information (aka personally identifiable information or PII) like a person's name, home address, email or phone number, etc. as Identity, because the systems that will process this attribute assume it is not directly identifying information.
We'll use index.js in our server app and these four parameters to send an API request to Twilio. Then, we'll send a success message or an error back to the mobile app together with the Endpoint. We implement this logic in the /register endpoint, but this is not required. You can come up with your own API, and perhaps integrate it into a login or a session initialization flow.
Now that we've registered the client app with Firebase Cloud Messaging and created a Binding, it's time to send some notifications! Check out our Sending Notifications guide for more information.
Need some help?
We all do sometimes; code is hard. Get help now from our support team, or lean on the wisdom of the crowd by visiting Twilio's Stack Overflow Collective or browsing the Twilio tag on Stack Overflow.
