In this blog post, I provide a brief overview of Apple’s Push Notification Lifecycle and where IBM Bluemix fits in.
- This Blog Post is Part 3 of a Tutorial Series on IBM Bluemix and iOS Push Notifications.
- My aim in this Blog Post is to help you understand Push Notifications when it comes to Apple Mobile Devices (iPhones/iPods/iPads).
When it comes to including Push Notification functionality in your iOS mobile app, the functionality itself is quite simple and straightforward. It’s understanding the lifecycle of the Apple Push Notification Service (APNS) that’s a bit daunting. What i’ve done below is divide this lifecycle into smaller topics that I trust will have you understanding enough of how the entire service works, to allow you to confidently continue with this Blog Series.
The Push Notification
To start things off, let’s talk about the Apple Push Notification itself and how it works. The primary purpose of a Push Notification is to alert a user about something related to your Mobile App, when your Mobile App is not currently active and in the foreground on his/her device. These notifications could include:
- Informing a user that a new message is awaiting them in your Mobile App
- Informing a user that they’ve received a new request they need to action via your Mobile App
- Scheduling a reminder for the user
- And the list goes on…
So, there are 2 types of Notifications:
- Local Notifications
- Remote Notifications (Also generally known as Push Notifications)
A Local Notification appears the same as a Push Notification, but the difference is that a Local Notification is created by your Mobile App on the Mobile Device it’s running on. An example of this is setting a reminder for the User. Your mobile app could set a Local Notification to run immediately or at a certain date and time.
A Remote Notification (Push Notification) is sent from a Cloud Server (e.g. IBM Bluemix) to Apple’s Push Notification Service, which in turn delivers it to your device. An example of this is when a message needs to be sent to the user from another device that has your Mobile App installed.
Push Notifications can appear as an alert, a badge or a banner and can play a sound when it appears on the user’s device. While a Push Notification contains standard values relevant to what’s required for it to appear on the user’s device, it can also contain custom data relevant to your Mobile App that can be used by your Mobile App to trigger certain actions.
When a Push Notification is triggered by the User of the device (e.g. swiping the notification), an action is sent to launch your Mobile App on that device. Your Mobile App can then get a handle on the Push Notification that was triggered by the user. This in turn allows your Mobile App to perform the necessary actions based on the custom data received via the Push Notification.
The Apple Push Notification Service and the Provider
The APNS, in short, is responsible for delivering a Push Notification do your device. Here’s where the tricky part comes in though. Let’s create a quick scenario:
You have a Web Application that manages leave requests. When you submit a leave request to your manager for approval, you want he/she to receive a Push Notification on their mobile device. Many would think it’s as easy as sending the request directly from your Website to the APNS, but it’s not. There’s a middle layer between your Web Application and the APNS, and that layer is called “The Provider”.
The Provider (e.g. Bluemix, Appcelerator, AWS, etc) manages the Push Notification Requests from your Web or Mobile Application. The Provider then communicates with the APNS over a binary interface. I will not attempt to bore you with the technical details of how the Provider communicates with the APNS, but if you want you can read about it here.
What matters here is that you understand the flow of a Push Notification from your application, through to the targeted mobile device. The below image (From Apple) explains this flow once your Push Notification Request is sent to the Provider:
The Mobile Application
In case you’re still wondering, a Push Notification’s existence is dependent on a Mobile App running on a user’s mobile device. You cannot send a Push Notification to a mobile device if there’s no mobile app to receive that Push Notification.
When your Mobile App is installed and launched on a user’s device, the Mobile App, if configured to receive Push Notifications, will register with the Apple Push Notification Service. Once registered, the APNS will send a device token back to the mobile device, who in turn delivers the device token to your Mobile App. Your Mobile App needs to then deliver the device token to the Provider (Bluemix), who also registers the user’s device.
Once this process is complete, your Mobile App is ready to receive Push Notifications via the device it’s installed on. What’s great about Bluemix as a Provider, is that they provide the necessary SDKs for iOS which allows the mobile device to be automatically registered on the Bluemix Cloud if registration with the APNS was successful.
What you as an iOS Developer should know
The key to getting all of this going is to understand Apple’s certificate requirements. Your Mobile App needs to have the necessary profiles and certificates installed in order to register for Push Notifications. Setting up the certificates is the trickiest part of this entire Blog Series.
My next blog post will focus on setting up these Provisioning Profiles and Certificates. Once we’ve got that monster out the way it’s all smooth sailing.
Cheers for now