Scheduled Notifications
Sometimes an app may need to schedule a message to be displayed to the user at a future date. One way to achieve this, without relying on the user to have the app open to display the message, is to use a scheduled notification. Scheduled notifications present a dialog to the user at a predefined date and time that provides the user with the following three options:
A snooze button allows the user to postpone the notification for several minutes. The snooze period can be set by the user when using a reminder.
A dismiss button allows the user to close the notification.
Tapping elsewhere within the notification dialog launches your app.
The Windows Phone notification system consists of two types of notifications: alarms and reminders. These provide a simple way to link back to your app and do not depend on your app being in the foreground. Figure 32.1 shows an alarm being displayed.
Note
Tapping an alarm or reminder launches your app. If your app is in the foreground and the user taps the alarm, the alarm dialog is dismissed.
The two types of scheduled notifications are represented by the Alarm and Reminder classes. Both types may be set to be periodic, occurring every day, for example, or set to occur only once.
Registration of a notification is done using the ScheduledActionService class, which is demonstrated later in this section. ScheduledActionService handles the registration of both scheduled notifications and scheduled tasks.
Note
Although scheduled notifications offer an effective and easy way to link back to your app, there is a limit to how many can be registered by your app. This limit is 50 alarms and reminders in total. Attempting to register more than this number raises an InvalidOperationException.
Alarm and Reminder classes are derived from the ScheduleNotification class, which contain a Content property and a Title property that are displayed to the user (see Figure 32.2).
Note
The Title property is supported only by the Reminder class and not by the Alarm class. Alarm overrides the Title property, and its setter raises a NotSupportedException if it is used. When the alarm notification is displayed, the title in the alarm dialog is always Alarm.
The most important distinction between alarms and reminders is that reminders allow you to deep link to your app. This means that a URI can be associated with the reminder, so that when the user taps the reminder, your app is launched to a specific page and you can determine the course of action based on the URI’s query string. While tapping an alarm also launches the app, it does not provide an equivalent URI property.
Another distinction between the Alarm and Reminder classes is that the Alarm class includes a Sound property, which allows you to specify the sound file to play when an alarm occurs, which the Reminder class does not.
The time and date of the notification are specified using the ScheduledAction.BeginTime property, which is of type DateTime. The date component of the BeginTime property is relevant only when using a RecurrenceType of None. RecurrenceType defines if, and for what period, scheduled notification should be periodically presented to the user. If the value is None (the default), the notification is raised only once.
When setting the BeginTime property of a notification, the value must fall after the current time or an InvalidOperationException ensues.
The ScheduledAction.ExpirationTime property is used to define the window for which the notification is raised; when the date and time on the phone occur after the ExpirationTime value, the notification schedule expires and the notification is no longer raised. If not specified, ExpirationTime is set to DateTime.MaxValue, resulting in it never expiring.
The following sections examine the use of each notification type in greater detail.