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. Local notifications are available in iOS only.
- 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.Push notifications are available in both iOS and, beginning with Mac OS X v10.7 (Lion), Mac OS X.
The following sections describe what local and push notifications have in common and then examine their differences.
Note: For usage guidelines for push and local notifications in iOS, see “Enabling Push Notifications” in iOS Human Interface Guidelines.
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 there is something of interest for them.
Let’s say 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 operating system on your 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.
Figure 1-1 A notification alert
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.)
Mac OS X Note: Currently, the only type of push notification in Mac OS X for non-running applications is icon badging. In other words, an application’s icon in the Dock is badged only if the application isn’t running. If users have not already placed the icon in the Dock, the system inserts the icon into the Dock so that it can badge it (and removes it after the application next terminates). Running applications may examine the notification payload for other types of notifications (alerts and sounds) and handle them appropriately.
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.
For both local and push notifications, 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—or, in Mac OS X, clicks the icon in the dock—to launch the application, which then displays the to-do item or whatever else is of interest to the user.
Figure 1-2 An application icon with a badge number (iOS)
In iOS, 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.
Figure 1-3 A notification alert message with the action button suppressed
The operating system delivers a local or push notification to an 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 (in iOS) 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 (available only in iOS) 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 iOS application or a Mac OS X application 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 or computer; 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 or computer 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 the operating system of a device or computer; the operating system, 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 (on iOS) and the application is properly registered, the notification is delivered to the operating system 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, but without the additional overhead. For an application that is not currently running—or, in the case of iOS, not 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 application is running when a notification comes in, the application can choose to handle the notification directly.
iOS Note: Beginning with iOS 4.0, applications can run in the background, but only for a limited period（期间）. Only one application may be executing in the foreground at a time.
As its name suggests, Apple Push Notification service (APNs) uses a push design to deliver notifications to devices and computers. A push design differs from its opposite（相反的）, a pull design, in that the immediate recipient（接受着） of the notification—in this case, the operating system—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 or computer comes online and has not received the notification, APNs pushes the stored notification to it. A device running iOS receives push notifications over both Wi-Fi and cellular connections; a computer running Mac OS X receives push notifications over both WiFi and Ethernet（以太网） connections.
Important In iOS, Wi-Fi is used for push notifications only if there is no cellular connection or if the device is an iPod touch. For some devices to receive notifications via Wi-Fi, the device’s display must be on (that is, it cannot be sleeping) or it must be plugged in. The iPad, on the other hand, remains associated with the Wi-Fi access point while asleep, thus permitting（允许） the delivery of push notifications. The Wi-Fi radio wakes the host processor（主处理器） for any incoming traffic.
Adding the remote-notification feature to your application requires that you obtain the proper certificates（证书） from the Dev Center for either iOS or Mac OS X 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.
THE END !
JASON