Service Bus Notification Hubs are a brand new intrinsic feature of Windows Azure Service Bus and are different from other push notification services in four key areas:

  • Complete client registration management. Your backend application (if you even have one) does not need to worry at all about device-ids or channels or other particulars of push notifications and doesn't need to cooperate in management. It doesn't even have to be a web app that's publicly accessible.  
  • Platform independence. Service Bus Notification Hubs allow cross-platform push notifications so that iOS Alerts and Windows Live Tiles can be targeted with a single event message. 
  • Broadcast and tag-based Multicast - Service Bus Notification Hubs are optimized around automatic notification broadcast to many thousand devices with low latency. One message in, thousands of notifications out.
  • Mass customization - Notification Hub notification templates allow for customization of notification delivery for each individual registration, allowing each instance of a client App to choose how it wants to receive events.

In this preview, Notification Hubs are able to push notifications to Windows Store apps and iOS apps from .NET back-ends. Support for Android and Windows Phone, along with additional back-end technologies (including Windows Azure Mobile Services) will be added soon.

After the basic intro, I'm showing how to create and provision a Windows 8 application from scratch, how to hook it up to a new Notification Hub, and send it a notification "Toast" using the portals and Visual Studio 2012. (The equivalent iOS walkthrough will follow later this week)

For those of you with a "TL;DW" attention span (too long; didn't watch), here's the whole extent of the code added to the stock Windows Store Grid template to enable Service Bus Notifications and that includes re-registering existing registrations at App startup. 5 lines without cosmetic wrapping and some massaging of XML for the template:

public App()
    var cn = ConnectionString.CreateUsingSharedAccessSecretWithListenAccess(
    this.notificationHub = new NotificationHub("myhub", cn);


async Task InitNotificationsAsync()
    await notificationHub.RefreshRegistrationsAsync();

    if (!await notificationHub.RegistrationExistsForApplicationAsync("myToast"))
        await notificationHub.CreateTemplateRegistrationForApplicationAsync(
            CreateTemplate(), "myToast");
XmlDocument CreateTemplate()
    var t = ToastNotificationManager.GetTemplateContent(ToastTemplateType.ToastText01);
    var n = t.SelectSingleNode("//text[@id='1']") as XmlElement;
    if (n != null)
        n.InnerText = "$(msg)";
    return t;

The event-source code is similarly terse:

var cn = ServiceBusConnectionStringBuilder.CreateUsingSharedAccessSecretWithFullAccess(
    "clemensv1", "{{{secret key}}");

var hubClient = NotificationHubClient.
    CreateClientFromConnectionString(cn, "myhub");

hubClient.SendTemplateNotification(new Dictionary<string, string>{
    { "msg", TextBox1.Text }});

3 lines. Three lines. No management of device ids. No public endpoint for the phone to talk to. Service Bus does all that. It really is worth playing with.

And here are all the key links ....



Friday, March 15, 2013 9:29:43 PM UTC

Is there a way to have the server taking care of client hub registrations? Would it be possible to build an app in which clients would exchange notifications between themselves by talking to the server and not directly by posting to the hub?

The reason for this is simple: hub communication can easily generate non-trivial Azure costs. By going through the server the software vendor stays in the control of the traffic and can charge clients accordingly. There are other benefits too, such as being able to abstract out (hide) details of client-to-client communication from the client.

Is there a way to pass enough information from a client to the server so that the server take over from there and manage a hub on behalf of a client, without the client ever knowing that there is a notification hub somewhere?

Thanks for any hint/suggestion!
Saturday, March 16, 2013 9:07:23 AM UTC
Sorry for the noise, I just realized that the clients can have only the listen permission in that particular scenario. They can ask the server to send notifications to other clients.
Comments are closed.