Local and Push Notifications in Depth

The essential purpose of both local and push notifications is to enable an application to inform its users that it has something for them—for example, a message or an upcoming appointment—when the application isn’t running in the foreground. The essential difference between local notifications and push notifications is simple.

• Local notifications are scheduled by an application and delivered by iOS on the same device.

• Push notifications, also known as remote notifications, are sent by an application‚Äôs remote server (its provider) to Apple Push Notification service, which pushes the notification to devices on which the application is installed.

The following sections describe what local and push notifications have in common and then examine their differences.

Push and Local Notifications Appear the Same to Users

From a user’s perspective, a push notification and a local notification appear to be the same thing. But that’s because the purpose is the same: to notify users of an application—which might not currently be running in the foreground—that it has something of interest for them.

You’re using your iPhone—making phone calls, surfing the Internet, listening to music. You have a chess application installed on your iPhone, and you decide to start a game with a friend who is playing remotely. You make the first move (which is duly noted by the game’s provider), and then quit the client application to read some email. In the meantime, your friend counters your move. The provider for the chess application learns about this move and, seeing that the chess application on your device is no longer connected, sends a push notification to Apple Push Notification Service (APNs).

Almost immediately, your device—or more precisely, the iOS running on the device—receives the notification over the Wi-Fi or cellular connection from APNs. Because your chess application is not currently running, iOS displays an alert similar to Figure 1-1. The message consists of the application name, a short message, and (in this case) two buttons: Close and View. The button on the right is called the action button and its default title is “View”. An application can customize the title of the action button and can internationalize the button title and the message so that they are in the user’s preferred language.

If you tap the View button, the chess application launches, connects with its provider, downloads the new data, and adjusts the chessboard user interface to show your friend’s move. (Pressing Close dismisses the alert.)

Let’s consider a type of application with another requirement. This application manages a to-do list, and each item in the list has a date and time when the item must be completed. The user can request the application to notify it at a specific interval before this due date expires. To effect this, the application schedules a local notification for that date and time. Instead of specifying an alert message, this time the application chooses to specify a badge number (1).

At the appointed time, iOS displays a badge number in the upper-right corner of the icon of the application, such as illustrated in Figure 1-2. The badge number is specific to an application and can indicate any number of things, such as the number of impending calendar events or the number of data items to download or the number of unread (but already downloaded) email messages. The user sees the badge and taps the application icon to launch the application, which then displays the to-do item.

An application can specify a sound file along with an alert message or badge number. The sound file should contain a short, distinctive sound. At the same moment iOS displays the alert or badges the icon, it plays the sound to alert the user to the incoming notification.

Notification alert message can have one button instead of two. In the latter case, the action button is suppressed, as illustrated in Figure 1-3. The user can only dismiss these kinds of alerts.

The operating system delivers a local or push notification to an iOS-based application whether the application is running or not. If the application is running when the notification arrives, no alert is displayed or icon badged or sound played, even if the device screen is locked. Instead, the application delegate is informed of the notification and can handle it directly. (“Scheduling, Registering, and Handling Notifications” discusses the various delivery scenarios in detail.)

Users of iPhone, iPad, and iPod touch devices can control whether the device or specific applications installed on the device should receive push notifications. They can also selectively enable or disable push notification types (that is, icon badging, alert messages, and sounds) for specific applications. They set these restrictions in the Notifications preference of the Settings application. The UIKit framework provides a programming interface to detect this user preference for a given application.

More About Local Notifications

Local notifications are ideally suited for applications with time-based behaviors, including simple calendar or to-do list applications. Applications that run in the background for the limited period allowed by iOS might also find local notifications useful. For example, applications that depend on servers for messages or data can poll their servers for incoming items while running in the background; if a message is ready to view or an update is ready to download, they can then present a local notification immediately to inform their users.

A local notification is an instance of UILocalNotification with three general kinds of properties:

• Scheduled time. You must specify the date and time the operating system delivers the notification; this is known as the fire date. You may qualify the fire date with a specific time zone so that the system can make adjustments to the fire date when the user travels. You can also request the operating system to reschedule the notification on some regular interval (weekly, monthly, and so on).

• Notification type. This category includes the alert message, the title of the action button, the application icon badge number, and a sound to play.

• Custom data. Local notifications can include a dictionary of custom data.

“Scheduling Local Notifications” describes these properties in programmatic detail. Once an application has created a local-notification object, it can either schedule it with the operating system or present it immediately.

Each application on a device is limited to the soonest-firing 64 scheduled local notifications. The operating system discards notifications that exceed this limit. It considers a recurring notification to be a single notification.

More About Push Notifications

An application on an iPhone, iPad, or iPod touch is often only a part of a larger application based on the client/server model. The client side of the application is installed on the device; the server side of the application has the main function of providing data to its many client applications. (Hence it is termed a provider.) A client application occasionally connects with its provider and downloads the data that is waiting for it. Email and social-networking applications are examples of this client/server model.

But what if the application is not connected to its provider or even running on the device when the provider has new data for it to download? How does it learn about this waiting data? Push notifications are the solution to this dilemma. A push notification is a short message that a provider has delivered to a device; the device, in turn, informs the user of a client application that there is data to be downloaded, a message to be viewed, and so on. If the user enables this feature and the application is properly registered, the notification is delivered to the device and possibly to the application. Apple Push Notification Service is the primary technology for the push-notification feature.

Push notifications serve much the same purpose as a background application on a desktop system. For an iOS-based application that is not currently running in the foreground, the notification occurs indirectly. The operating system receives a push notification on behalf of the application, and alerts the user. Once alerted, users may choose to launch the application, which then downloads the data from its provider. If an iOS-based application is running when a notification comes in, the application can choose to handle the notification directly.

As its name suggests, Apple Push Notification Service (APNs) uses a push design to deliver notifications to devices. A push design differs from its opposite, a pull design, in that the intended recipient of the notification—in this case, iOS—passively listens for updates rather than actively polling for them. A push design makes possible a wide and timely dissemination of information with few of the scalability problems inherent with pull designs. APNs uses a persistent IP connection for implementing push notifications.

Most of a push notification consists of a payload: a property list containing APNs-defined properties specifying how the user is to be notified. For performance reasons, the payload is deliberately small. Although you may define custom properties for the payload, you should never use the remote-notification mechanism for data transport because delivery of push notifications is not guaranteed. For more on the payload, see “The Notification Payload.”

APNs retains the last notification it receives from a provider for an application on a device; so, if a device comes online and has not received the notification, APNs pushes the stored notification to it. A device receives push notifications over both Wi-Fi and cellular connections.

Adding the remote-notification feature to your application requires that you obtain the proper certificates from the iPhone Developer Program portal and then write the requisite code for the client and provider sides of the application. “Provisioning and Development” explains the provisioning and setup steps, and “Provider Communication with Apple Push Notification Service” and “Scheduling, Registering, and Handling Notifications” describe the details of implementation.

Apple Push Notification Service continually monitors providers for irregular behavior, looking for sudden spikes of activity, rapid connect-disconnect cycles, and similar activity. Apple seeks to notify providers when it detects this behavior, and if the behavior continues, it may put the provider’s certificate on a revocation list and refuse further connections. Any continued irregular or problematic behavior may result in the termination of a provider's access to APNs.

---