WP8.1 Tiles and Notifications

Editor's Notes

• #7: Let’s start with some of the tile terminology. Peek is the term we use to describe a tile that has 2 parts to it. On a tablet, this will look like a top and a bottom of the tile. On a phone, this will look like a front and a back as the tile flips from one to the other.
• #11: http://msdn.microsoft.com/en-us/library/windows/apps/dn393983.aspx
• #18: http://code.msdn.microsoft.com/windowsapps/app-tiles-and-badges-sample-5fc49148/
• #24: In addition to there being a lot of types of notifications, there are a lot of ways to send those notifications. You can schedule your notification, which will queue the notification into a system process and run it at a specific time. You can schedule a periodic update, which will pull the notification from a URL at a specified time interval. You can raise a notification from within the foreground or background of your application. Or you can use the Windows Notification Service Push Service to send a notification to your app. Lets dig into each of these.
• #25: Let’s start with scheduled updates. We start from our application and within this application we call the Scheduler notification APIs. (click) Let’s look at the code that makes this happen. (click) Line 1: Walking through the code: We create a scheduled toast notification using the xml document that defines our tile, badge or toast notification and we add a time. In this case, it scheduling this notification to fire 1 day from now. Line 2: We create a notification manager… in this case, it is a toast notification manager. Line 3: We add our notification to the scheduler. And we’re done! (click) That puts the notification into the system schedule queue. The system will check that queue to see when it needs to execute the queue itesm and, when the time is right, it will push that toast or tile to be the live tile for your app.
• #26: Periodic updates require us to create the tile at a secondary service. We can set that service in our application with this code. (click) In which we set up a pointer to where we want to call for our tile code. Then we simply start the update at the frequency we prefer, which can be as much as a day or as little as 30 minutes. (click) This will register our update with the Windows System Services which will check for the update at the appropriate time. (click) It will then use the Tile an Badge Updater APIs to request a new tile. (click) It will send an HTTP Request for that tile XML payload. (click) And use that payload to update the tile.
• #27: Periodic updates are particularly cool because they can actually be done without any client side code. (click) Just open the package.appmanifest and in the application tab, you can set the tile update with the frequency you want and just paste in the URI template you want to use.
• #28: Local notifications are nice and straightforward. We start in your app, either in the foreground or the background. (click) Then we create a tile, badge, or toast notification based on the XML document. The, using the Tile, Badge, or Toast updater, we simply call the update. (click) And using the Tile, Badge, and Toast APIs, our tiles badges or toasts are immediately notified of the update. One important note is that calling a toast update on your app from the foreground will do nothing. We will only get a toast notification if we call it from the background.
• #29: From this table we can see that not every notification option is available to every kind of notification. We can’t send badges as scheduled notifications. We can’t send toasts as periodic notifications and we can only send raw notification through the push notification service.
• #30: One more thing about notifications: with this release of Windows we can place multiple tiles into a notification queue. (click) We can place up to 5 tile notifications in that queue and the tile will cycle through those notifications. (Click) Then we can replace a tile in that queue with another tile or (click) set expirations for those tiles. To think of what kinds of the scenarios this enables, imaging there is a sports fan following multiple games, or a news reader that can list the 5 most important stories, all from 1 tile.
• #31: efore you can send notifications using WNS, your app must be registered with the Windows Store Dashboard. This will provide you with credentials for your app that your cloud service will use in authenticating with WNS. These credentials consist of a Package Security Identifier (SID) and a secret key. 
• #32: Previous to this release, Microsoft had Microsoft Push Notification Services (MPNS) driving notifications on the phone and the Windows Notification Service (WNS) drive notifications on Windows devices. But now push notifications on Windows devices are driven by the Windows Notification Service, which delivers push notifications across all devices. (click) We’ve integrated the push registration service so that we have one process for all devices to register your app to handle these push notifications. (click) And, as previously mentioned, we have one set of tile templates that drive push across all devices to simplify the process of driving those key tile experience on Windows Phone.
• #33: The architecture behind WNS are this: Your windows phone application contacts the Windows Notification Client platform to request a channel URI, which is a push uri unique to that device and application. Register this Uri with your cloud service. Save that Uri in your service so you can use it to push notifications to the device. Authenticate your service WNS. The cloud service authenticates with WNS by providing its credentials (Package SID and secret key) and getting back an access token that allows your service to send a notification. Then you can send that notification with that token to the push notification service. For more information: http://msdn.microsoft.com/en-us/library/windows/apps/hh465435.aspx
• #34: Here, we’re just going to do a quick walk-through of setting an app up for push notifications. Right-click on your phone project and go down to the Store section to associate your app with the store.
• #35: This will pull up a wizard for associating your app with the store. Sign in with your Microsoft account and walk through the wizard and you will be able to see all the app names that you’ve provisioned through your store account. If you haven’t yet reserved an app name, you can actually do that here.
• #36: As you finalize your association, you’ll be given the final package name and publisher ID.
• #37: But you don’t even need to keep track of these because when you finalize the association, it will add the file Pachage.StoreAssociation.xml to your project.
• #38: With that in place, we can start the push process we outlines earlies. (click) We get our Channel URL with the following code and we save that Uri to our notification service. You’ll have to write this code yourself, but it would be a simple HTTP call to your service. (click) We can also add an event handler so that we can catch these notifications while our application is open.
• #39: In terms of the services for collecting your device channel URIs and authenticating to the WNS service, we have published a sample project for push notifications. You can see how that project runs at http://pushtestservce.azurewebsites.net/wns If you’re looking for a turnkey solution to abstract the notification handling away, you could also turn to the Microsoft Azure Notification Hub, which you can use to deliver cross-device notifications as well as take advantage of the Azure scaling as your notifications start to ramp up. 
• #40: But I can hear you saying “I don’t want to write and host a service just to write the push component of my app”. The Windows Phone team listened and have responded by integrating a notification simulator into the tools. Let’s take a look at how this tool works.
• #54: http://msdn.microsoft.com/en-us/library/windows/apps/hh779725.aspx