With the release of the new SDK developers also gained access to a new set of APIs. One of these revolves around the OS-based alert mechanism. If you’ve used a NoDo (or pre-NoDo) device and activated a standard system alarm or used the calendar to schedule an appointment, you know what an alert will look like.
There are tow types of system alerts that can be invoked from a third-party application – reminders (represented by the Reminder class) and alarms (represented by the Alarm class). Both have separate purposes, but the idea remains the same. Let’s take a look at a quick example:
The Reminder class here is used to simply display an on-screen notification (without any additional sounds) that will let the user know that an action happened or has to happen. The reminder carries both a begin time – when it is started and shown to the user, and an expiration time – when the alert expires and is removed from the alert queue.
NOTE: Make sure that you are using a time that is in the range of the current system time (read: time on the phone) in order for your alert to start correctly. Otherwise, an exception will be thrown:
The recurrence type can be set manually and will occur as long as the application is installed until it is explicitly removed from the queue.
The reminder itself can be linked to any application element through an URI. The alert is persistent – even if the application is deactivated, the reminder will still be triggered at the specified time.
ScheduleActionService is the link to the system alert scheduler that will put the alert in the queue. After a bit of digging through the class via Reflector, it becomes clear that it invoked SystemNotificationInterop to create and dispose new and existing notifications.
NOTE: SystemNotificationInterop carries a reference to PlatformInterop.dll – a native DLL that is used to access low-level system capabilities from managed code.
Ultimately, I get something like this:
If I click on the reminder (anywhere in the message zone), I will be taken to the URL (relative to my app). The application title will always be displayed in the header, above the title. I can snooze the reminder – only in case I want to be reminded about the same action after a period of time. The RecurrenceInterval property still applies here.
NOTE: Adding new notifications to the same application notification poll should be done with a new name for each separate notification. Otherwise, an exception will be thrown. The notification poll is kept active as long as the application is installed and running.
Another type of an alert is the Alarm. It does not have a navigation URI, so whenever it is triggered, it is used only as a notification with a sound – nothing more. Clicking on the alarm message will simply transport the user to the calling application. Also, it doesn’t support a title.
NOTE: When adding a new alarm, make sure there is no name conflict with any other alerts. The notification poll doesn’t see a structural difference between a Reminder and an Alert. That being said, a Reminder instance named “My Reminder” will conflict with an Alert instance named “My Reminder”
One distinctive feature of the Alarm class is the ability to set a sound as an alarm. Take a look:
file1.mp3 is a local file that is copied as Content. Currently, it seems like there is no access to the system sounds, so all sounds set for alarms should be passed internally from the application itself. If no sound is passed, the default system alarm sound is used.
Fun Fact: The sound URI should be local. No external URIs are accepted and any attempts to do so will cause this: