Taler sammeln, Statistiken einsehen, das Auto im Blick behalten – ihr alle kennt die TankTaler-Features. Doch wie funktioniert die technische Welt dahinter? Auch von dieser wollen wir berichten. Deshalb heute von dem TankTaler-Technik-Team (Yes, gleich 4x T!) der erste Blog-Eintrag.
Herzlichen Dank an unseren iOS-Developer Niko 🙂
Silent push notifications are a feature, released by Apple with iOS 7 that gives you a bit more flexibily with using push notifications.
Before that, there was little an application could do in order to affect how the system handles pushes. One was just sent by your servers, received by the device and shown to the user. In fact, before people interact with them, there’s hardly a way for the app to even know there is one.
For many use cases, this is working just fine. However, as soon as your app needs a little more information to properly handle its pushes, things get worse.
And in a platform that is so strict about background execution, that can be a problem. I’m sure most of you have been is this situation at some point.
Your project desperately needs that piece of information from your server, but it’s not in the foreground so the only way to make the connection is via push notifications.
However, everytime you send something, the user immediately sees it in the phone’s lock screen. Not ideal…
So how are silent push notifications any different? As opposed to their non-silent counterparts, they give the application a chance to process a push, before it’s shown to the user.
In fact, the app might decide to not show a notification to the user at all.
It’s nice to see Apple easying their notorously strict policy regarding multitasking. As you will soon realize, it’s still not perfect, but it can really help for many projects.
Once a silent push notification is received by a device, the corresponding application is “woken up” in order to process the received information.
This happens in the
– (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler;
method. You might notice that it’s quite similar to the conventional method for getting pushes:
– (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo;
Of course, the difference is that the latter will only be invoked once the user actually interacts with a push.
This new `AppDelegate` method’s job is to execute some third-party code that can determine what to do in response to that new information.
After that, if it chooses, it can schedule a local push notification that will actually be reflected on the phone’s screen.
Lets now look at that extra parameter provided by the new AppDelegate method. A quick look in to the iOS developer reference page, reveals the following text:
„As soon as you finish processing the notification, you must call the block in the handler parameter or your app will be terminated. Your app has up to 30 seconds of wall-clock time to process the notification and call the specified completion handler block. In practice, you should call the handler block as soon as you are done processing the notification. The system tracks the elapsed time, power usage, and data costs for your app’s background downloads. Apps that use significant amounts of power when processing remote notifications may not always be woken up early to process future notifications.“
If you’ve ever worked with long running background tasks in iOS, this is probably familiar to you. The basic “contract” in this case is that Apple has blessed you with some sweet background execution time as long as you promise (pinky swear ever) that you’ll let them know, via the completion handler, that you’re done. Oh, and by the way, this needs to happen within around 30 seconds.
Break that promise, and you’ll be horribly slaughtered the task manager. And you don’t want that.
Another thing you might notice is that the completion handler actually has a parameter of type `UIBackgroundFetchResult`. Possible values are:
Stepping back for a second, as far as Apple is concerned, silent push notifications are an extension to the [background fetch][Background fetch resources link]. So reading about them, you naturally encounter a lot of background fetch references.
`UIBackgroundFetchResult` is exactly that. Using its values you can specify if you were able to fetch some new data as a result to your background execution. If you don’t necessarily have any meaningful information to convey in your completion handler, it should be ok to just return `UIBackgroundFetchResultNewData` or `UIBackgroundFetchResultNoData`.
To be continued…