Ready to send your first notification? Of course you're not! That's why you're here. But don't worry, 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 (iOS) 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 these two components work together when you register for notifications. Let's get to it!
Before working with Twilio Notifications, we'll need to register our device with APNS. This registration will happen every app launch, and in our AppDelegate and we can specify the type of notification (sound, alert, or badge) that we'd like to accept. On the first launch, iOS will prompt us to enable push notifications with a popup alert.
Once we've enabled notifications, iOS will send an asynchronous response to the app via the didRegisterForRemoteNotifications function. Make sure you've properly configured your iOS app for notifications or else the registration won't work.
Once we've received a successful registration response from the didRegisterForRemote NotificationsWithDeviceToken method, it's time to create a Binding. A “Binding” represents a unique device that can receive a notification. It associates a unique device token (provided by iOS) with an identity and an optional set of tags that you define for your application. When you want to send a notification, Twilio will send your notification only to Bindings that match the parameters you specify (more on that later).
The client app should send a request to the server containing the device token and any additional information the server might need to create the binding (typically Identity and BindingType). We'll use the NSURLSession networking API that is part of the iOS standard library to make the request. You could also use another library, such as AFNetworking or Alamofire.
The last step on the client side is storing the Endpoint identifier generated by Twilio and included in the response. Storing the Endpoint and reusing it in subsequent requests will allow us to avoid creating duplicated Bindings when the device token changes. Here we use the KeychainAccess helper class from our quickstart app but you can use your own way of accessing the keychain.
In our server app, we’ll receive the POST request. It’ll contain the following four parameters.
|Identity||The Identity to which this Binding belongs. Identity is defined by your application and can have multiple endpoints.|
|BindingType||The type of the Binding determining the transport technology to use. We will use
|Address||The device token obtained from iOS.|
|Endpoint||The identifier of the device to which this registration belongs. This is generated the first time you create a Binding. Then you need to store it in the keychain and provide it in your subsequent registrations to avoid duplicating Bindings even if the device token changes.|
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 call to Twilio, using the next generation Twilio Node Helper Library. This will help us create a new Binding. We implement this logic in the /register endpoint, but this is not required. You can come up with your own API, perhaps integrate it into a login or a session initialization flow.