MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

Managing Channel URIs (Service)
If you use the code in the previous section, your web service that generates push notifications will
receive HTTP POST requests with unique channel URIs for each and every tile. This isn’t the only way to
transport channel URIs, of course; in fact, because a channel URI might be used to transmit personal
information through notifications, it should ideally be encrypted with a private key before it’s sent to
the server. Otherwise someone could possibly intercept that URI and use it to redirect user-specific
notifications.
In any case, the service must expect to receive—and then manage—a unique URI for each
app/user/device combination. This underscores the fact that push notifications are best used for
user-specific notifications rather than broadcast notifications. In the latter case, setting up a service for
periodic updates is a much easier solution.
Once the service receives a channel URI along with any data to identify the user and the purpose of
the channel, it should securely save that information in persistent storage of some kind, such as a SQL
Server database (for an ASP.NET service) or a MySQL (for a PHP service).
It’s important that the service also removes obsolete channel URIs. If it receives a new URI for the
same user and the same purpose, it should replace the old with the new. It should also remove any URIs
from its data store if it receives an HTTP 404 or 410 error back from WNS, indicating an obsolete
channel.
A simple ASP.NET service page that can receive a post from Scenario 1 of the Push and periodic
notifications client-side sample can be found in the HelloTiles website project in this chapter’s
companion content, specifically receiveuri.aspx. To run this service, make sure you have the localhost
established, as described earlier in the “Using the localhost” section for periodic updates. You may also
need to install ASP.NET on your localhost. An easy way to do this is to obtain the Background transfer
sample, go into its Server folder, and then from an administrator command prompt run powershell
-ExecutionPolicy unrestricted -file serversetup.ps1. If you then run the site in Visual Studio Express
2012 for Web as we did before, you should have a localhost port for the service (for instance,
http://localhost:52568/HelloTiles/receiveuri.aspx).
You can then set a breakpoint in the service code, paste the service URI into Scenario 1 of the Push
notifications sample, and press its Reopen Channel And Send To Server button. This should hit the
breakpoint in the service and allow you to step through the code that processes the request. Here you’ll
find that the request contains channelUri and itemId values (along with LOGON_USER), which can be
saved for when the service needs to send a notification to WNS. Something similar can be written in
other server-side languages, of course, and a great place to find tools to help with writing services is the
Windows Azure Toolkit.
Sending Updates and Notifications (Service)
Before a service can send updates, it must to authenticate itself with WNS by sending the Package
Security Identifier (SID) and client secret as obtained through the Windows Store Dashboard. This is a
610