Sending Windows 8 Push Notifications using Windows Azure Mobile Services
Recently we announced the preview of Windows Azure Mobile Services. In this blog series I will detail how to build a Windows Azure Mobile Service to send push notifications of varying types to your Windows 8 applications.
This series will walk through creating a push notification scenario using WNS and Windows Azure Mobile Services.
As I post each part I will update the links below and tweet as the post is available. So lets get started with Part 1 – Azure Mobile Services and Push Notifications an Overview
Part 1: Windows Azure Mobile Services and Push Notifications an Overview
What is Windows Azure Mobile Services?
Here is an info-graphic on the current Windows Azure Mobile Services stack I pulled together as part of a presentation I recently gave at TechEd. It’s important to note that this info-graphic captures Mobile Services today and over time you will see the feature set of Mobile Services grow exponentially with subsequent releases.
The goal of Windows Azure Mobile Services is to make it incredibly easy for developers to add a cloud backend to their client apps be it a Windows 8, Windows Phone, iOS or Android application. To do this we provide a number of turn key features baked right into the Mobile Services experience. As the diagram depicts Mobile Services today provides:
- Structured Storage
- ability to store structured data to a SQL Database using dynamic schema without being concerned with writing underlying T-SQL.
- If using single database apps are automatically partitioned by schema e.g AppX.Todoitem, AppY.Todoitem
- If you want access to your data you are not locked out and can manage it in a number of ways including the Mobile Service Portal, SQL Portal, SQL Management Studio, REST API etc.
- Server Logic
- Service API: Mobile services automatically generates a REST API to allow you to perform CRUD operations from your client application on your structured storage
- With Dynamic Schema (enabled by default), your Mobile Service will automatically add columns to tables as necessary to store incoming data.
- Ability to author server side business logic directly in the portal that is executed directly within the CRUD operation pipeline
- Makes it easy for your users to Authenticate against Windows Live. Other major identity providers are coming soon.
- The REST API can be locked down using table level permissions using a simple drop down. No complex code required. Available permissions levels include: Everyone, Anyone with an Application Key, Only Authenticated Users, Only Scripts and Admins. These permissions can be set individually on each table and can granularly control each CRUD operation of each table.
- More granular control can be added using server side scripts and the user object
- Push Notifications
- Integrates with WNS to provide Toast, Tile and Badge Notifications.
- WNS auth is made easy with the portal captures your WNS client secret and package SID
- the server side script push.wns.* namespace performs WNS auth for you and provides a clean and easy object model to compose notifications
- Common tenants of Windows Azure Services
- Compute – scale between shared and reserved mode, increase/decrease your instance count
- Storage – ability to scale out your mobile service tenant(s) to a dedicated SQL DB. Ability to scale up your SQL DB from web through business to 150GB.
- View diagnostics directly in the portal including API calls, CPU time and Data Out
- Console.* operations like console.log and console.error provide an easy means to debug your server side scripts.
Today we provide client libraries for Windows 8 to make consuming mobile services easy. For more details on what client libraries (Windows 8, Windows Phone, iOS and Android) are supported at the time of reading please see: Mobile Services and Mobile Service Reference.
What are Push Notifications?
The Windows Push Notification Services (WNS) enables you to send toast, tile, badge and raw notifications from the cloud to your Windows Store applications even when your app is not running. Push notifications are ideal for scenarios when you need to target a specific user with personalized content.
The following diagram depicts the general Lifecycle of a push notifications via the Windows Azure Notification Service (WNS). We’ll walk through the steps shortly but before doing so I thought it would be important to call out that as a developer implementing a push notification scenario all you need to do is implement those interactions in grey and the applications/services in blue. Fortunately Mobile Services makes a great deal of this easy for you as you will see throughout the reset of this series.
The process of sending a push notification boils down to three basic steps:
- 1. Request a channel. Utilize the WinRT API to request a Channel Uri from WNS. The Channel Uri will be the unique identifier you use to send notifications to your application.
- 2. Register the channel with your Windows Azure Mobile Service. Once you have your channel you can then store your channel and associate it with any application specific data (e.g user profiles and such) until your services decide that it’s time to send a notification to the given channel.
- 3. Authenticate and Push Notification to WNS. To send notifications to your channel URI you are first required to Authenticate against WNS using OAuth2 to retrieve a token to be used for each subsequent notification that you push to WNS once you have this you can compose and push the notification to the channel recipient. The push.wns.* methods make this task exceptionally quick to accomplish compared to writing it all from scratch yourself.
All in all Windows Azure Mobile Services makes all these concepts and steps and incredibly simple to implement though its structured storage and push notifications features. This series will walk through creating a push notification scenario using WNS and Windows Azure Mobile Services.
As I post each part I will update the links below and tweet as the post is available