Windows RT is that version of Windows that runs on low power ARM devices. I think for most people the pros and cons of this architecture are pretty clear already.

Usually the first upside argument is the significantly longer battery life it offers, and that’s certainly the case. Windows RT’s restricted architecture limits the processes that are running at any given point to only those modern apps that are designed to respect mobile users and their limited batteries. That’s a really great thing for users.

Besides the battery argument, however, I have another strong case for Windows RT that I’d like to share. By the way, I work at Microsoft, but I don’t have any influence on the teams that make these kinds of decisions, so I’ll just say that I hope that the Windows RT level or something like it sticks around. Here’s my case.

I have a friend that just installed a new shower for my wife and I. It’s a doozy too. Two shower heads and everything. Now we’re living in luxury.

This contractor friend of mine and his wife are… how to say nicely… far better with a tile saw than a computer. Computers aren’t their thing. At the same time, they run a small business and work with real estate, and so their job demands they spend a certain amount of time in front of a glowing screen.

We all know folks like these who spend 90% of their time in a browser, an email client, and the Office suite. And the other 10% of is spent waiting for the system to boot and launching the browser, email client, or Office suite.

These folks have a hard time getting work done anymore, because they’re overwhelmed with malware. Malware sucks, and there’s not really a good resolution. No matter what platform or browser is used, the consumer still wields the power to authorize the installation of malware. And if they don’t know any better, they will.

But malware is pretty much a moot point in the modern app ecosystem, and Windows RT devices are all but immune to it. The only code that can execute is built in or being executed out of an app package.

We’re dealing now with a whole new model for delivering code to people - it’s one where code is authorized and restricted. Code has to declare itself and its intent and it has to pass the test.

So, I recommend to my friend that they get a Windows RT device that performs the primary tasks (browser, email, and Office) brilliantly, but doesn’t offer any hope at all for the malware authors that would like to ruin their days.

This, in my opinion is a very strong case for this version of the OS.

I can put a Surface RT or some other Windows RT device in the hands of even my closest relatives and not expect support calls with complaints of malware. I’ll get support calls for other things I can be sure, but not for malware, and that is a big leap forward in my opinion.

Process Lifetime Management (PLM) is also known as the Application Lifecycle, but don’t confuse it with Product Lifecycle Management (also PLM) or with the general Application Lifecycle Management (ALM).

By Microsoft’s conventional definitions and in the best of my understanding, Process Lifetime Management and Application Lifecycle are one and the same, are defined (for Windows 8) here, and are defined as such…

This topic describes the lifecycle of an app, from the time it is deployed through its removal. By suspending and resuming your app appropriately, you ensure that your customer has the best possible experience with your app.

The means by which an app developer considers and targets the lifecycle of an app is well documented on the above page and in a few other blogs I found with some easy searching, so let’s consider that outside the scope of this quick study.

I’d just like to define some terms and share a little utility I made to help you understand what’s happening and when. Emphasis on the word little please.

The application’s state is one of three logical values: Running, Not Running, or Suspended. That’s easy. And the values are easy to understand when you look at this diagram…

But the actual states that an app can be in are actually enumerated (in JavaScript) in the ApplicationExecutionState object as notRunning, running, suspended, terminated, and closedByUser.

When you’re writing code for your app - even in the onactivated function that lives by default in the default.js file of your project - the value of the app’s state isn’t all that helpful, since it will always be running.

But what you might be interested in is the applications state the last time the app was running - you know, before it got activated. And that’s available in the onactivated function under args.detail.previousExecutionState. You might need to know this to, for instance, determine that Windows had to terminate the app due to resource constraints.

The other value you’ll be interested in when your app gets activated is the activation kind. The activation kind is the means by which this app was launched. At first, you might wonder how an app can be launched besides you touching the app tile on the start screen. There are a myriad of ways though let me assure you. In Windows 8.1, there are 23.

In the simple case, your app was launched by the user, so the value of the args.detail.kind variable is simple launch (actually it’s the integer value of the Windows.ApplicationModel.Activation.ActivationKind enumeration), but the user may also have executed a protocol handler that is registered to your app (protocol), opened a file whose type is registered to your app (file), launched your app via Cortana (voiceCommand), or one of 19 more.

And now the little utility.

LifeCycleState is on github at github.com/codefoster/LifeCycleState.

Run it and it simply shows the previous app state and the means by which the app was launched. Something like…

Hopefully it’s helpful for understanding the different states and activations kinds there are and when or how you trigger them. Run it through a few scenarios such as opening the app. Try switching to another and then back (activation does not occur). Try using various means of closing the app (ALT + F4, swipe from the top, swipe from the top and hold at the bottom of the screen until the tile flips, mouse click the X in the top right, etc.). Also, don’t forget about the Lifecycle Events that you can trigger using Visual Studio. Look for this button…

There you have it.

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.

Steps 1-3. Your app asks Windows for a channel.

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.

https://bn1.notify.windows.com/?token=AgYAAABrcyAqFeh...wfOG5%2bD4TCeHU%3d

By the way, the channel that Windows gives you also includes an expiration time which may be helpful.

Step 4. Your app sends this URI to your cloud service

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…

First message

POST /accesstoken.srf HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: https://login.live.com
Content-Length: 211

grant_type=client_credentials&client_id=**ms-app%3a%2f%2fS-1-15-2-2972962901-2322836549-3722629029-1345238579-3987825745-2155616079-650196962**&client_secret=**Vex8L9WOFZuj95euaLrvSH7XyoDhLJc7**&scope=notify.windows.com

It’s just a simple POST to login.live.com/accesstoken.srf. The 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
Cache-Control: no-store
Content-Length: 422
Content-Type: application/json
{
  "access_token":"EgAcAQMAAAAALYAAY/c+Huwi3Fv4Ck10UrKNmtxRO6Njk2MgA=",
  "token_type":"bearer"
}

With that, your service has what it needs to submit notifications to be pushed to your app.

Second message

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
Content-Type: **text/xml**
X-WNS-Type: **wns/tile**
Authorization: Bearer **EgAcAQMAAAAALYAAY/c+Huwi3Fv4Ck10UrKNmtxRO6Njk2MgA=**
Host: bn1.notify.windows.com
Content-Length: 32
<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

Step 6. WNS sends the notification to your app

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.

As you likely know Windows 8 is coming in the near future. You can download, use it, and even develop apps for it today. At this point in time, the Windows Store is not open for everyone to deploy, but we are looking for the first wave of great applications which highlight the power of Metro and Windows 8, especially those developers that want to get to market first and build the awareness and brand for their applications.

In order to submit your application today, you need a token which is something I can help you get.

What do you need to do to get a token? Here are the key steps:

1. Create a great application or game and get it ready.
2. Let me know about it by contacting me via jeremy.foster@microsoft.com
3. I’ll help you register so you can get your application through our Application Accelerator Labs where the app will get reviewed to confirm it is done and conforms to the Metro guidelines and certification requirements.

This is a great opportunity to not only be first to market with your app, but also to get feedback from a Microsoft Services Engineer to make your app great. If you are serious about creating an application this is a chance that you probably don’t want to pass up.

In addition, our team is holding a series of events and office hours to help you - we want to make sure you have what you need to be successful. You can come learn more about how to build apps for Windows 8 or show up and build your app with one of our evangelists or others in your community available to help you if you need it. You can find more information about our events and availability at…

Windows 8 Developer Camps

Redmond, WA (May 11)

Denver, CO (June 1)

Chandler, AZ (June 8)

Windows App Accelerator Labs

Los Angeles, CA (May 8-10)

Redmond, WA (May 15-17)

Mountain View, CA (May 22-24)