CC BY
17APPLE PUSH NOTIFICATION SERVICE Quynh H.1, Thao L.2, Hieu L.3, Khoe N.4, Thuong T.5, Uyen V.6
1Quynh Ho Van - Master's Degree Student, DEPARTMENT OF COMPUTER SCIENCE AND CONTROL SYSTEMS, FACULTY OF CONTROL SYSTEMS AND ROBOTICS;
2Thao Le Duc- Student, DEPARTMENT OF GEOINFORMATION SYSTEMS, FACULTY OF INFOCOMMUNICATION TECHNOLOGIES;
3Hieu Le Van - Student;
4Khoe Nguyen Huu - Student, DEPARTMENT OF SECURE INFORMATION TECHNOLOGIES, FACULTY OF INFORMATION SECURITY AND COMPUTER TECHNOLOGIES;
5Thuong Tran Thi Mai - Student, DEPARTMENT OF COMPUTER SYSTEM DESIGN AND SECURITY, FACULTY OF INFORMATION SECURITY AND COMPUTER TECHNOLOGIES;
6Uyen Vu Thi Phuong - Student, DEPARTMENT OF IT IN THE FUEL AND ENERGY INDUSTRY, FACULTY OF LASER AND LIGHT ENGINEERING, ITMO UNIVERSITY, SAINT PETERSBURG
Abstract: in order to save battery power applications running in the background, it is allowed to perform a limited set of actions. But what if there is something interesting and you want to inform users, even if your application is not running from them? For example, you received a reply on Twitter, or his favorite team won the game, or dinner is ready. Since the app is not running, it can not be checked and to receive the data. Fortunately, Apple Corporation has provided a solution to this problem. Instead of constantly checking the event or perform any action in the background, you can create a server-side application that will perform these actions.
Keywords: service, device, notification, app, server.
To many developers, Apple Push Notification service (APNs) is a bit of a black box. And come to think of it. So let's talk about APNs on this article. So Apple Push Notification service is a service that sends notifications to iOS devices, whether the target app is in the foreground or in the background. So how does it work? Well for starters, you need two important configuration bits to make this happen. First off, the device token. You can basically think of this as the address of the device you want to talk to you, but one that's unique for your app. It's also not really the address of the device. You know how when rock stars check into a hotel, they use a fake name? Well, the device token is kind of like having that fake name. It lets the hotel manager know that, it's cool for you to visit your rock star friend, because you know the alias that they're checked in under. So when your app gets permission from your user to receive notifications, iOS talks to APNs and requests a device token, basically a fake rock star name which is then given to your app.
COBPEMEHHblE MННОВАЦMM № 2(16) 2017 | 20 |
LiJ
iOS Device
Fig. 1. Schema of sending notifications message
Now if you were just building an iOS app using nothing but APNs, you'd need to pass this token back to your server somehow. We'll get into what GCM does at a later point. When your server passes this device token back to APNs, it's your way of both identifying the device you want to talk to, as well as proving to APNs that you're allowed to notify that device in the first place. The next bit you need is the APNs certificate. This basically allows your server to talk to APNs securely. And hang on, we've got some massively oversimplified explanations coming your way. One common way for two devices to talk to each other securely is to use public and private key encryption. Alice encrypts messages using Bob's public key, which only he can decode on his side using his private key, and then vice versa. So let's imagine your server is Alice. And if you want to talk back and forth to APNs, you're going to need your own private key and APNs' public key. In some cases, like the openssl tool that you can run from the command line, you pass these two keys in separately. But for many third party tools, including Google Cloud Messaging, these two keys are combined together, along with some other information, into a "p12" file that we colloquially refer to as the APNs certificate. So let's look at what happens when we send off a notification via APNs using a little server that you might have. For starters, we'll use that certificate we just talked about, containing your private key and APNs' public key, so that you can talk securely to the APNs service [1]. Now when you send off a notification, you're going to need to include things like the notification message, badge count, or any associated data. And you're going to send all of that along with the device token. Now when APNs receives that token, it's going to do some verification. It'll make sure it's a valid token, it hasn't been revoked, and that it actually belongs to your app. At this point, if everything looks good, it will go ahead and schedule the delivery of that notification at some point in the future. When does it actually deliver it? Honestly, that's kind of up to Apple. And they're not super explicit about the logic they use. There are a lot of different factors involved though. But you can influence this by labeling your messages as high priority, in picture 2 which has a priority value of 10, or a normal priority, with a value of 5.
| 21 | COBPEMEHHblE MHHOBA^M № 2(16) 2017
"alert": "Hello, how are you?",
Secret rockstar alias: ab2S863 bdd8344 bc034sf
Fig. 2. Example of notification's code
A high priority message would be for something where the user might get upset if they don't receive their message on time. A chat message or a calendar reminder is a good example here. A normal priority message is for something less time critical. APNs will often group these messages and send them all at once as a way to conserve the user's battery. And they may even get throttled and not send at all. But still, it's a good way of respecting your user's battery. So if it's not an urgent notification, consider sending it normal priority. Now, what happens when your device receives the notification? It depends a lot on what's going on with your app at the time. If your app is in the foreground, iOS will simply hand the notification off to your app. It won't show any kind of display at the system level. That's completely left up for your app to deal with. If your app is in the background, iOS will commonly show a notification, usually as a banner up on top here, but it depends on your settings. And it will probably be listed in the Notifications panel as well. If the user selects that notification, your app will come back into the foreground. And at that point, your app has a chance to handle the notification. Now, there is one other attribute of notifications you should be aware of. And that is the content-available flag. The purpose of this flag is to tell iOS that this would be a good time for your app to do a little background work. For example, you might want to tell your news app that you have some breaking news available, and your app should go and download and refresh the day's top headlines. Now, these notifications always need to be sent as normal priority. And developers typically send these as silent notifications. That is, they're usually sent without an associated alert message or sound, so the user doesn't notice them. When iOS gets these kind of content-available messages, it will pass the notification along to your app. And your app will have up to 30 seconds, but it might be a little less, depending on certain factors to do whatever background work it needs to do, and then let iOS know that it's finished. That's APNs in an overly-simplified nutshell [2].
References
1. Apple Push Notification Service. [Electronic resource]. URL: https://en.wikipedia.org/wiki/Apple_Push_Notification_Service/ (date of access: 30.11.2016).
2. APNs Overview. [Electronic resource]. URL: https://developer.apple.com/library/conten t/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOvervie w.html#//apple_ref/doc/uid/TP40008194-CH8-SW1/ (date of access: 27.10.2016).
COBPEMEHHbE MННОВАЦMM № 2(16) 2017 | 22 |
