Topics

Topics

We're finishing up our extensive look into the new Notifications improvements in iOS 10 today with Notification Service Extensions. These fill out the notifications functionality by allowing us to intercept remote notifications as they are received on the device, take some action(s), and then modify the notification before it's shown to the user. Let's get started!

We'll begin by looking at the broad concept going on here. Until iOS 10, Remote Notifications were presented to the user as soon as they arrived, without any interaction from their app.

In iOS 10, Apple has provided a mechanism for us to actually "intercept"Remote Notifications when they arrive, do some work, modify the notification's content, then send it along to be displayed to the user.

The whole process now goes like this:

This new step opens up a ton of possibilites and gives us a chance to do things like download media, or perform some other short work to enrich the notification before the user sees it.

Let's try this out.

First, we'll add another new target to our app, and choose a Notification Service Extension:

In the new group that was created we'll find one file, a subclass of UNNotificationServiceExtension.

Notification Service Extensions run in the background, and never show any kind of interface themselves. Instead, they override one function that's called whenever a notification is received.

We're passed in a notification request and a completion closure.

The request is the same UNNotificationRequest type we first learned about in Bite #258, only with its triggerproperty set to a UNPushNotificationTrigger, neat!

We'll perform whatever work we need, grab the content from the the notification request's, modify its properties, and then send it along in the completion closure:

Here we take advantage of the custom "userInfo" dictionary our server adds to the push notification payload. In this case, we're grabbing an asteroidID from it. We also grab a mutable instance of the notification's content so we can modify it later.

Then we load the details for the asteroid, and append a new piece of information to the notification's body, the estimated mass.

Finally, we send the modified content along in the contentHandler.

We don't need it here, but there's one more function we can override, and it's all about expiration.

Unlike some other more generous extension points, Notification Service Extensions are given an extremely short window to perform work and complete by the system.

We can override:

overridefuncserviceExtensionTimeWillExpire(){}

This will tell us when the system is about to forcibly stop our extension, if this happens, the system will display the notification using whatever push notification payload our server sent through, with no modifications.

In our example above, we lean on this fallback behavior, so we didn't need to override this function.

Finally, we'll push an example notification through using Knuff, (covered in Bite #177), and try this all out:

Success!

Topics

Topics

We've been looking at the various improvements in Notifications in iOS 10, and today we're trying out one of the coolest new features: Notification Content Extensions. These allow us to display completely custom content when the user drags down or 3D Touches on one of our app's notifications. Let's dive in.

We'll start by adding a new target to our app and choosing Notification Content Extension.

We'll give it a name, and check out the files we get.

Like many of the other extension types we've covered, the whole thing is basically a view controller, storyboard, and Info.plist.

We'll head to the Info.plist first and configure a few things.

Since we want our custom content to be all that's visible once the users opens up our notification, we've added the UNNotificationExtensionDefaultContentHidden key hide the title and body text labels that are visible before open

We've also set our notification category to match the one we'll send in our UNNotificationContent.

Before we continue, let's add some actions to our notification so the user can actually do something about it. We've covered Notification Actions in the past (Bite #122), but here's how things work in the User Notifications Framework world:

// Somewhere before we request our first notification:letevade=UNNotificationAction(identifier:"evade",title:"Evade with Autopilot 🤖")letdestroy=UNNotificationAction(identifier:"destroy",title:"Destroy (Weapons to Maximum!) ",options:[.destructive])

Topics

Topics

Today we'll continue our look at Notifications in iOS 10 by checking out some new capabilities for interacting with the user's notification preferences, and also the notifications we've requested and setup with the notification center. Let's begin.

First up, we finally have a way to "ask" the system for the user's current notification preferences state:

Inside this fancy UNNotificationSettings object is a wealth of detail about exactly how the user has configured our app's notifications to work. Everything from authorizationStatus to alertStyle. Neat!

Next up, since we've been requesting all these notifications to be triggered, we can now ask the system to give us the list of pending notifications. (Notifications that are scheduled, but haven't been displayed yet).

UNUserNotificationCenter.current().getPendingNotificationRequests{requestsin// requests is an array// of UNNotificationRequest objects.}

From here, we can take the identifier of any of these requests, and use it to (for example) "unschedule" it:

The categoryIdentifier here is simply a unique string we create. Later, we'll use this to identify "Asteroid Detected"notifications and differentiate them amongst from other kinds of notifications our app might display.

Topics

Topics

Push Notifications were a fantastic addition to iOS in iOS 3. They can also sometimes be tricky to test and debug. We can save ourselves a ton of time and hassle with OS Xapp called Knuff. Today we'll check it out and see what it can do. Let's get started.

Before we begin, we'll install the free Knuff iOS app to make our lives a little easier in a few minutes.

We'll launch it on our iOS device (on the same Wifi network as our Mac). Knuff will display a new Devices button for us to choose our device, then it will in our push token for us.

Knuff helps us by finding all the identities in our Keychain and letting us pick. (We can create a new push certificate/identity for our app with one command using fastlane's pem tool).

That's it! We can now use Knuff to configure our payload, and send pushes. Knuff even lets us save our configurations into files that we can open later for testing different notifications and scenarios.

We'll be working in an imaginary Groceries app. The app currently notifies users when they're running low on something. We're going to make things even better by letting the user re-stock their pantry right from the notification banner.

funcapplication(application:UIApplication,handleActionWithIdentifieridentifier:String?,forRemoteNotificationuserInfo:[NSObject:AnyObject],withResponseInforesponseInfo:[NSObject:AnyObject],completionHandler:()->Void){// handle the action, based on its identifiercompletionHandler()}

Topics

Topics

Local Notifications are a way to display a system notification to a user of your app without needing to implement a push server. You simply schedule them using an NSDate and they are presented at that time. Let's take a look.

Register for Notifications

Since iOS 8, we've had two different things to register for: User Notifications and Remote notifications. Since we'll be “sending” Local Notifications, we only need to register for User Notifications.

This will prompt the user for permission to see notifications, except instead of coming from a backend server, they'll be generated locally on the device.

Schedule a Local Notification

After we get the didRegisterUserNotificationSettings callback, we're ready to schedule a notification. We use the UILocalNotification class to configure all the aspects of how the notification will look and behave:

Topics

Topics

CloudKit lives on the client. You write Swift or Objective-C code to interact with Apple's iCloud servers to save and retrieve data. But what if your app wants to support push notifications? Don’t worry CloudKit has you covered. Use CKSubscription to tell CloudKit you'd like to know when records matching a predicate are created, updated, or deleted. CloudKit will deliver a special push notification to your app denoting the change, which you can customize for your needs.

Let's take a look at setting it up: (don't forget to setup and register for push notifications!)

Then when you receive the push notification use it's userInfo to create a CKNotification object and grab the ID of the new record:

letnotification:CKNotification=CKNotification(fromRemoteNotificationDictionary:userInfo)ifnotification.notificationType==CKNotificationType.Query{letqueryNotif=notificationas!CKQueryNotification// do something interesting with queryNotif.recordID}