Posts tagged with "mobile development"
You want your app to be successful and to be successful, you must think about the user.
Windows 8 thinks about the user through and through. It puts the user in control of what shows up on their start screen, when the app bar and charms bar appear over their content, and what apps have the capability of doing on their machine.
When you’re working on your app, consider that the user is not always just launching your app and then closing it when they’re done. They may be using your app as one in a series of apps involved in a single usage scenario.
Consider this usage scenario…
Your app helps users make restaurant dinner reservations.
Your user may use your app on its own, but more likely your user…
- steps onto an escalator at the airport
- checks their trip management app to find their hotel’s location
- checks for restaurants in the hotel’s vicinity
- picks a restaurant based on user reviews
- makes a reservation at the restaurant (with your app!)
- sends the reservation confirmation to a colleague
- and then steps off the escalator
That user is a delighted user. He has not just used an app. He has accomplished something significant in very little time. All during the escalator ride, the complimentary and informative animations were important, all of the thought that went into the UX of each app was very important, and the app-to-app sharing was crucial.
Keep that in mind as you formulate your app idea, as you design your app, and as you implement the Windows 8 contracts.
I can hardly stand not knowing how something works under the hood. More often than not, I’d rather have a working knowledge of a system than the convenience or function of the system itself. It’s why I chased degrees in Computer Electronics and Computer Engineering in the first place. I don’t know so much about all of the fancy things that engineers put into processors and primary system boards these days, but I’m relieved to have at least a fundamental understanding of a control bus, a machine clock, a MOSFET, an assembly program, and the higher level software abstractions. But I digress…
What I want to talk about right now is the anatomy of a push notification message. I was intimidated by the subject when I was first introduced to it, but I’ve climbed on top of the general concept now and feel confident enough to post on the matter.
I do have to say that I’m pretty excited about the convenience of Windows Azure Mobile Services (WAMS) abstractions over the process, but I don’t want to use it blindly without understanding what it’s doing under the hood. I’m going to start with a review of the process and players in a typical push notification. You can find this diagram and an overview of the process here.
The green is you and the blue is Microsoft. You are writing an app and you are responsible for a cloud service to communicate with WNS.
In my typical attempt to make complex sound easy, I’m going to walk you through this process.
You ask Windows for a channel, Windows asks WNS (this happens transparent to you), and then Windows gives you a channel. This channel is just a string. Here’s a sample URI with an ellipse since it’s actually much longer.
By the way, the channel that Windows gives you also includes an expiration time which may be helpful.
You can use whatever means you choose, but I would hope that you’d find a smart and secure way to do that. A potential attacker would have to get this URI and also your Package Security Identifier and Client Secret in order to start sending malicious app notifications, but still.
Step 5. Your cloud service asks WNS (Microsoft’s server) for an access token and then triggers a push
Here’s where the bulk of the “magic” happens. Your service does two HTTP calls. The first gets it an access token (which you’ll likely want to cache), and the second (and subsequent) initiates a push to your app. WNS knows where your app is because of the URI that you sent it.
Here are examples of those two raw HTTP messages…
POST /accesstoken.srf HTTP/1.1
It’s just a simple POST to
client_id is actually the Package Security Identifier (SID) that you get from your developer dashboard at http://dev.windows.com, and the
client_secret is the Client Secret that you find in the same place.
The response to a successful access token request is something like…
HTTP/1.1 200 OK
With that, your service has what it needs to submit notifications to be pushed to your app.
Your service has the access token and that’s all it needs to issue requests for WNS to push to your app.
Here’s a push message that changes the text on your tile…
POST **https://bn1.notify.windows.com/?token=AgYAAABrcyAqFeh...wfOG5%2bD4TCeHU%3d** HTTP/1.1
Authorization: Bearer **EgAcAQMAAAAALYAAY/c+Huwi3Fv4Ck10UrKNmtxRO6Njk2MgA=**
<tile><visual><binding template="TileSquareText03"><text id="1">Message sent from push</text></binding></visual></tile>
Notice a few things about this message…
- Just like the request for an access token, this is a secure post to https
- The message is sent to the channel URI
- You can find valid values for the Content-Type and X-WNS-Type headers here
- The Authorization header always has that word Bearer, a space, and then the access token received from the first call
This step is all on WNS and Windows and you don’t have to do anything except for verify that the process worked.
And there you have it. You can find numerous services that wrap this process for you and make it easy, but now you know the guts of what’s going on under the hood. It’s not exactly something you want to try to explain to your mom, but it’s not exactly quantum physics either.