The chart above plots the total number of known Surface RT 1 units that connected to MarkedUp’s services over the course of the past year.

As you can see, the Surface RT 1 had sluggish adoption in early 2013 but rapidly accelerated beginning in March / April – the likely cause of that growth is due to Microsoft’s introduction of the Surface RT tablet into new markets and additional promotions /exposure described earlier.

However, the Surface RT’s growth really exploded around the June / July 2013 timeframe – right when the Surface’s prices slashed. Bear in mind that late Summer and Winter are Microsoft’s two strongest sales quarters for consumer products – “Back to School” and “Holiday” sales respectively.

Average number of monthly Surface RT 1 units sold prior to price drop

105,452 monthly units

Average number of monthly Surface RT 1 units sold after to price drop

358,044 monthly units

As you can see from the data table above, the monthly sales volume of Microsoft’s Surface RT 1 units tripled following the price cut – moving from roughly 100,000 units per month to 350,000 per month.

We plotted the net number of new devices per month to help confirm this:

You can see a big ramp up of sales in July and August, followed by a drop in September. That’s natural – back to school sales typically end by Labor Day in early September, so there’s going to be a big drop following August.

But what’s really telling about this graph is that the number of units sold in September is still greater than what was sold in July (another strong B2S sales month), which is unusual. Here’s the raw data table to supplement the chart.

Surface RT 1 Worldwide Adoption January 2013-2014

Month

New Devices

Total Devices

2013-01

75,535

75,535

2013-02

72,701

148,236

2013-03

83,678

231,914

2013-04

96,134

328,048

2013-05

120,522

448,570

2013-06

184,140

632,710

2013-07

246,299

879,009

2013-08

339,794

1,218,803

2013-09

249,798

1,468,601

2013-10

318,291

1,786,892

2013-11

321,131

2,108,023

2013-12

556,965

2,664,988

2014-01

474,030

3,139,018

It was generally believed that issues with the Windows 8 and Surface RT user experience were the tablet’s primary barriers to adoption. It is our conclusion that the real issues might have been awareness and price sensitivity.

So why is the Surface product line starting to look healthier for Microsoft now? Is the Surface 2 or Surface Pro such a drastic improvement over the Surface RT tablets that it’s been able to single-handedly double Microsoft’s Surface revenue? Not exactly.

By the end of December 2013, we started seeing roughly 60,000 new Surface RT 2 devices activated per month – a pretty good start for a new device that’s still trying to build up brand recognition with consumers.

However, its older cousin, the Surface RT 1, sold well over 500,000 copies in December.

Surface RT 1 vs. Surface RT 2 Devices Activated per Month

Month

Surface RT 1

Surface RT 2

2013-01

75,535

0

2013-02

72,701

0

2013-03

83,678

0

2013-04

96,134

0

2013-05

120,522

0

2013-06

184,140

0

2013-07

246,299

0

2013-08

339,794

131

2013-09

249,798

130

2013-10

318,291

10,315

2013-11

321,131

34,476

2013-12

556,965

62,905

2014-01

474,030

61,340

Total

3,139,018

169,299

Conclusion

It’s difficult to reconcile this data with the theory that the Surface RT 1’s inability to meet Microsoft’s original sales estimate was due to the product design itself, if you assume that the Surface RT 2 is an improved product (which it is.)

Aside from the innate improvements made to the Surface 2 and its novelty, the only other major difference between the two generations of Surface is price. Microsoft moves many times more tablets when the starting price point is at $349 versus $499.

In a subsequent update, we will perform a similar analysis for the higher-end Surface Pro and Surface Pro 2 tablets.

MarkedUp’s Collection Methods

Our data is collected from apps that are installed directly onto end-user machines, so our data set is limited to “devices that have installed an app that uses MarkedUp.”

That being said, this data set is covers roughly 10% of all Windows 8 machines ever sold. Our numbers for Windows Phone are similarly impressive, but excluded from this data-set (naturally.)

There is some latency between when a device is sold to an end-user and when we “discover” it by way of an app installation; however, having been in market since before Windows 8 was launched, our data set has historically mirrored the market as it moves in real-time. We see giant surges on Christmas morning, after Black Friday, and so forth.

Devices can be counted multiple times, depending on the number of installed apps from distinct MarkedUp-enabled publishers and the version of our SDK that was used. Our facts and figures accurately reflect trends and changes in direction in the market, but not precise figures.

These reports are anonymized aggregations of our entire data-set.

The data in this report tracks the number of net new devices activated on our platform per month, starting from January 2013 to January 2014.

Like many developers, the MarkedUp Analytics team is naturally excited to try new things; that being said – we also don’t like having to wipe a dev machine and re-image it in the event that a beta release of Windows isn’t compatible with tools we use for doing our jobs every day.

So, we use Hyper-V or VirtualBox and run Windows 8.1 in a VM until it’s released to market.

For now we’re going to leave the VM’s network as “Not Connected” – we’ll create a Virtual Network Adapter for it later.

If you already have a Hyper-V virtual network adapter that can share Internet connectivity with the host machine, use it here. Otherwise we’ll add one later after the OS installation on the VM is complete.

Windows 8 needs at least 20GB of disk space on a 64-bit system. I’m going to give this VM 40GB and I’m going to use a dynamically expanding disk.

Dynamically expanding disks will be slow initially, but it saves room on the host machine in the event that you don’t occupy the entire VHD volume immediately.

If speed is an issue, you can create a fixed-size disk up front.

3. Install Windows 8.1 Preview from ISO

Now we’re going to use the Windows 8.1 Preview .ISO file we downloaded earlier to install the operating system while we finalize our VM.

This option will have you complete the Windows 8.1 Preview installation the first time the VM boots, using the .ISO file you downloaded earlier as the bootable media.

With all of those steps complete, you should now see the “Windows 8.1 Preview” VM on your Hyper-V list:

Select the Windows 8.1 Preview VM and start it, and you should see the first “Install Windows” screen after a few seconds:

Click next.

You’ll need to enter in a product key for Windows 8.1 Preview during the first part of the installation process.

If you see the following message and it asks you to choose between an upgrade and a custom installation, Select “Custom: Install Windows only.”

Install Windows 8.1 on the VHD that we created earlier.

Let the Windows 8.1 Preview installation run to completion. And after 30 minutes or so you should be able to create a local Windows account and log in.

4. If you don’t have one already, create a Virtual Network Adapter for Windows 8.1

If you didn’t have a Virtual Network Adapter ready during step 2, we’ll create one now.

First, shut down your Windows 8.1 Preview VM and turn it off – we’re about to make some changes to it.

Open up the Hyper-V manager and go to “Virtual Switch Manager.”

Select “New virtual network switch.” Give the switch a name and make it an External Network. If you have multiple physical network adapters (i.e. ethernet and WiFi), use whichever one you use most often. Check the “allow management operating system to share this network adapter” box.

Apply changes.

Go back to your VMs and right click on the “Windows 8.1 Preview” VM you created – select “Settings,” then select “Network Adapter.”

Change the Virtual switch to the new switch you just created; mine is called “Magical Switch.”

Apply changes. Before we try starting the VM, let’s make sure that our switch was set up correctly – I often have trouble getting Hyper-V’s network adapters to behave properly the first time around.

Go to Control Panel and then to View Network Connections. Right click on the new switch you just created and select Properties.

Only the following properties should be set:

Client for Microsoft Networks

QoS Packet Scheduler

File and Printer Sharing for Microsoft Networks

Microsoft LLDP Protocol Driver

Link-layer Topology Discovery Mapper I/O Driver

Link-layer Topology Discovery Responder

Internet Protocol Version 6 (TCP/IPv6) and

Internet Protocol Version 4 (TCP/IPv4)

You will likely need to reboot your host machine in order to get the Internet working again. Go ahead and do that now.

5. Start Windows 8.1 Preview; Profit

You now should be able to start your Windows 8.1 VM in Hyper-V and connect to the Internet.

Please give this guide a try and let us know if you run into any trouble!

We wanted to expand on what we shared in the presentation itself and share some of our applied knowledge on how to put Cassandra to work in the field of real-time analytics.

Let’s start by helping you understand how an analytics system needs to be built.

Real-time Analytics and the CAP Theorem

For those of you who aren’t familiar with Brewer’s CAP theorem, it stipulates that it is impossible for any distributed computer system to simultaneously provide all three of the following guarantees:

Consistency;

Availability; and

Partition tolerance.

In the real-world all distributed systems fall on a gradient with each of these three guarantees, but the kernel of truth is that there are trade offs. A system with high partition tolerance and availability (like Cassandra) will sacrifice some consistency in order do it.

When it comes to analytics, there’s a transitive application of the CAP theorem to analytic systems – we call it SCV:

Speed is how quickly you can return an appropriate analytic result from the time it was first observed – a “real-time” system will have an updated analytic result within a relatively short time of an observed event, whereas a non-real-time system might take hours or even days to process all of the observations into an analytic result.

Consistency is how accurate or precise (two different things) the analytic outcome is. A totally consistent result accounts for 100% of observed data accounted for with complete accuracy and some tunable degree of precision. A less consistent system might use statistical sampling or approximations to produce a reasonably precise but less accurate result.

Data Volume refers to the total amount of observed events and data that need to be analyzed. At the point when data starts to exceed the bounds of what can be fit into memory is when this starts to become a factor. Massive or rapidly growing data sets have to be analyzed by distributed systems.

If your working data set is never going to grow beyond 40-50GB over the course of its lifetime, then you can use an RDBMS like SQL Server or MySQL and have 100% consistent analytic results delivered to you in real-time – because your entire working set can fit into memory on a single machine and doesn’t need to be distributed.

Or if you’re building an application like MarkedUp Analytics, which has a rapidly growing data set and unpredictable burst loads, you’re going to need a system that sacrifices some speed or consistency in order to be distributed so it can handle the large volume of raw data.

Think about this trade off carefully before you go about building a real-time analytics system.

What Data Needs to be Real-time?

“Egads, ALL DATA SHOULD BE ALWAYS REPORTED IN REAL-TIME!” shouted every software developer ever.

Real-time analysis is important for operational metrics and anything else you or your users need to respond to in real-time:

Error rates or health monitoring;

Dynamic prices, like stock prices or ticket fares;

On-the-spot personalizations and recommendations, like the product recommendations you might see when browsing Netflix or Ebay.

In these scenarios, the exact price or the exact error rate isn’t as important the rate of change or confidence interval, which can be done in real-time.

Retrospective or batch analysis is important for product / behavior analysis – these are metrics that tell you how you should or shouldn’t do something, and they are data that you can’t or shouldn’t respond to in real-time.

You don’t want to redesign your product based on fluctuations during day-to-day use – you want to redesign it based on long-term trends over all of your cohorts, and it naturally takes a long time for that data to accrue and be analyzed / studied.

In this type of analysis it’s more important for the data to be comprehensive (large) and accounted consistently.

Analytic speed is always a trade-off between data volume and consistency – you have to be concious of that when you design your system.

The one property you’re never going to want to intentionally sacrifice is data volume – data is a business asset. Data has inherent value. You want to design your analytic systems to consume and retain as much of it as possible.

At MarkedUp we use a blend of both real-time and retrospective analytics:

In this post and the next we’re going to focus on how we use Cassandra for real-time analytics – we use Hive and Hadoop for our retrospective analysis.

Why Cassandra for Real-time Analytics?

Cassandra is highly available and distributed; it has high tolerance to individual node failures and makes it possible to add multi-data center support easily if data affinity or sovereignty is an issue. On top of that it’s easy to expand a Cassandra cluster with new nodes if necessary (although this shouldn’t be done frivolously since there is a high cost to rebalancing a cluster.)

It has amazing write performance; we’ve clocked Cassandra writes taking up to 200µs on average for us, and that’s doubly impressive considering that most of our writes are big, heavily denormalized batch mutations.

Batch mutations give us the ability to denormalize data heavily and update lots of counters at once – in Cassandra it’s generally a good idea to write your data to make it easy to read back out, even if that means writing it multiple times. Batch mutations make this really easy and inexpensive for our front-end data collection servers.

Distributed counters were added to Cassandra due at Twitter’s insistence, and they’re a major boon to anyone trying to build real-time analytic systems. Most of MarkedUp’s real time analytics are implemented using counters – they provide a simple, inexpensive, and remarkably consistent mechanism to update metrics and statistics at write time. There are some trade offs (namely the loss of idempotency) but they make up for it in simplicity and speed.

Physically sorted columns are one of the Cassandra database implementation details worth learning, because with it you can create easily predictable and pre-sorted slices of data. This makes for really efficient storage of time-series data and other common types of analytic output. When you combined physically sorted columns with dynamic columns and slice predicates you can create lookup systems which retrieve large data sets in constant time.

Dynamic columns are a Cassandra feature that takes getting used to, but they are enormously powerful for analytic workloads when coupled with sorted columns – they allow you to create flexible, predictable data structures that are easy to read and extend.

We’re going to publish a series of posts about working with Cassandra for real-time analytics. Make sure you read part 2 where we go into detail on our read / write strategy with Cassandra for analytics!

We made MarkedUp Analytics privately available to some Windows 8 developers in September, and thus we’ve had a chance to watch the Windows 8 ecosystem grow since well prior to its official 10/26 launch.

However, what about the Surface RT tablet Microsoft released on the same day? How well has it sold since?

MarkedUp Analytics was installed into some of the biggest apps in the Windows Store a month prior to the launch of Microsoft Surface; that puts us in a good position to use our data to make some educated inferences as to how well the Surface has really fared in the device marketplace.

Surface and the Windows 8 OEM Landscape

Before we jump into the specifics of Microsoft Surface, let’s consider the Windows 8 OEM ecosystem.

OEMs like HP, Dell, and Samsung still have a significant presence in the Windows 8 market, and the majority of it from devices that have been upgraded from Windows 7 and XP.

These traditional PC manufacturers also had a small, but statistically significant head-start over Microsoft in terms of total market share, because developers and big enterprises have had early access to the full verison Windows 8 since 8/15.

This chart represents total market share by OEM across all devices that have used an app with MarkedUp installed in it since 10/26 until 11/24/2012, spanning roughly one month since Windows 8 and Microsoft Surface officially launched.

According to our data set, Microsoft has only one device in market – the Surface RT tablet. Our data set showed that Microsoft had statistically 0.0% market share prior to 10/26*, the day Surface and Windows 8 officially went on sale.

Microsoft’s 7.77% market share on this chart is represented solely by the adoption of the Surface RT tablet, and making Microsoft the 4th most popular OEM among Windows 8 users currently.

This number is also reflected in our analysis across all Windows 8 device models, rather than manufacturers:

MarkedUp has observed 11,385 distinct Windows 8 device models as of 11/24, and most of them are upgraded Windows 7 / Windows XP devices.

Microsoft Surface is by far the single most-used Windows 8 device from this cornucopia of hardware, occupying roughly 7.76% of the market.

The next most-used device model is the Samsung Sens Series laptop, like the Series 9 ultrathin notebook, with 3.31% market share, less than half of what the Surface RT has.

So with all of this market share data in mind, what’s the adoption rate for Microsoft Surface thus far?

Microsoft Surface Adoption Rate

So how quickly has the Surface RT tablet been adopted worldwide?

Well, we don’t have the absolute numbers since MarkedUp doesn’t have 100% market penetration across every unique Windows 8 device (working on it!) but we do have more than enough data to draw some inferences about the rate as which Surface RT tablets are being adopted.

The following chart shows the cumulative growth of the Surface RT’s installation base:

As we mention in the callout on this chart, we decided that the best way to plot the growth of the Surface was to create an index and plot all of the cumulative growth relative to the index.

We set the index value 1 to be equal to the number of Surface RT tablets we saw activated on 10/26, the day it first went on sale. The final value on this chart has an index value of 120 for 11/24/2012, 29 days after the Surface went on sale initially – meaning that there were 120 times as many Surfaces activated by 11/24 than there were on 10/26.

So if Microsoft sold 10,000 Surfaces on day 1, then by the rate of growth on this chart they will have sold at least 1,200,000 units by 11/24.

Remember, this chart shows active devices that are being used and have consumed apps from the Windows Store, not devices that have been sold. The numbers on MarkedUp’s charts are effectively a floor for sales given that devices are sold before they’re used.

Microsoft Surface Adoption by Country

So we’ve shown you how quickly Surface RT tablets are being activated, but what about where they’re being activated?

In the chart above we broke out the percentage of Surface RT distribution by country including the 10 largest markets; the subsequent 60 markets all trail off quickly.

The United States has an overwhelming 68.52% share of all Surface RT tablets activated thus far with the UK coming in at a distant second with 9.10% share.

Our numbers across all Windows 8 devices are slightly different, but the US and UK both have dominate leads in those figures too.

One factor that may skew MarkedUp’s numbers towards the English-speaking world is that many app publishers forgo full international distribution in the Windows Store due to the fact that many parts of the world, including China and countries that have tighter content restriction laws, lengthen the Windows Store approval process and can even cause the app to be rejected outright.

So on that note, we strongly suspect that China in particular is under-represented on this chart given that it’s a massive market, but one that is more difficult for many app publishers to reach due to content restrictions.

Conclusions

Based on the data above, here is what we conclude:

The Microsoft Surface is the most heavily used ARM device in market for Windows 8 by a wide margin thus far and it is the single most-used device overall for Windows 8;

Surface’s growth appears to be strong, but it’s difficult to extrapolate the absolute number of units have been sold without knowing what the total day 1 sales were;

Surface RT is being adopted in primarily English-speaking countries, but has broad international reach; and

The majority of devices in market for Windows 8 are upgrades from previous versions of Windows, not new devices that came with Windows 8 installed; we’ll see how this changes as we collect more data from the Holiday season. The fact that the Samsung Sens Series made a strong appearance on our device model breakout shows signs of a growing ecosystem of net new Windows 8 machines from non-Microsoft OEMs.

Appendix

Here are some other interesting statistics from our OEM data set:

The remaining 24.48% OEM market share not shown on the OEM chart represents 296 long-tail, smaller OEMs including VMWare virtual machines and a number of motherboard manufacturers used in home-made PCs.

x64, 64-bit Intel hardware, is used by roughly 70% of the daily active usersfor the entire Windows 8 ecosystem every day;

x86, 32-bit Intel hardware, is used by roughly 20%; and

ARM, the new architecture for lightweight tablets like the Surface, is used by the remaining 10% of daily active users.

*MarkedUp observed some Microsoft Surface RT devices appear as early as 10/18 in our data set, but not enough to be statistically significant. We suspect that they were preview devices given to select app partners, press, and others with early access.

This week I’m attending //BUILD conference in Redmond, WA on Microsoft’s main campus alongside thousands of other .NET / Windows developers. The keynote ended about an hour ago and I wanted to publish my thoughts on some of the important takeaways from Ballmer’s talk.

Microsoft’s Points of Emphasis

1. “Microsoft can only win by training consumers to expect consistent behavior, availability, and synchronized data across all of their different devices”

WinRT isn’t just about tablets – it’s also about fundamentally changing the way desktop software is consumed and unifying mobile / desktop / tablet and probably console apps all under one consolidated platform.

The unification of these platforms is the future of Microsoft; training consumers to expect consistent behavior and access to data across all of their devices is the only way Microsoft will be able to dethrone Apple and Google in mobile / tablet and protect themselves in desktop / console in the long-run.

Ultimately, Microsoft is really the only company that can execute well on native software, services, and devices. They are playing to their strengths (ecosystem and platform) and are doing it well here.

2. “The fate of WinRT is in the hands of developers big and small.”

Microsoft desperately needs developers to make WinRT a success.

Microsoft, for the first time since Win32 emerged as the victor in the desktop wars of old, is in a position where it needs developers more than they need Microsoft.

The unified vision behind WinRT will not work without the buy-in of developers both big and small, from Facebook to the individual hobbyist developer.

Microsoft will do the hard work of putting devices in the hands of consumers that bring WinRT applications to the forefront (which I suspect is the real reason why the ARM-only Surface shipped so far ahead of the Intel one.) But it is totally reliant on developers to put the content in-store that consumers actually want to use.

3. “Microsoft and Nokia will work themselves to death to win the support of developers.”

Compounding key takeaway #2, Microsoft and Nokia both made commitments to put hardware (Nokia phones, Surfaces for us //BUILD attendees) into the hands of developers who build apps.

Having worked at Microsoft Developer Platform Evangelism throughout the entire WP7 push, I can tell you that this is no joke – Microsoft will find a way to arm its developers with hardware now that it’s all generally available.

But they’re not stopping there – Microsoft is going to continue to push training events, hackathons, webcasts, and everything it can possibly do to train developers and make it easier than ever to learn a new platform and actually ship an app on it.

I think this is tremendously positive and every developer who’s interested in the platform will have multiple opportunities to learn it on Microsoft’s dime.

4. “Don’t ship apps that don’t leverage the platform.”

Reading between the lines in some of the keynote speeches and the first couple of sessions I poked my nose in, you can interpret the following from Microsoft:

Developers who carbon copy their work byte-by-byte from previous platforms, including web apps, are doing themselves a disservice and will have their lunch eaten by developers who take advantage of charms, live tiles, and all of the other unique built-in features to Windows 8. Please take advantage of the platform if you’re going to build an app for it!

Here’s why: the success of Microsoft’s entire consumer software ecosystem rides on consumers adopting the Metro UI and getting used to the rest of Microsoft’s services ecosystem, which includes your apps in the Windows Store.

However, without a significant presence in mobile, Microsoft and Windows will always have the threat of a unified iOS / OS X ecosystem there to sweep the desktop market out from underneath it. Windows Phone 8 is not a side show – it’s part of the core front Microsoft is forming against Apple on consumer computing.

Parting Thoughts

This is a really exciting time to be a Windows developer. The opportunities for developers to build sustainable businesses around Windows 8 and Windows Phone 8 apps are huge and there for the taking.

On top of that, the ecosystem has never been more accessible – you can build native apps for Windows 8 and Windows Phone 8 with C# or C++, and I suspect we’ll eventually see WinJS apps make their way onto Windows Phone 8 too.

That’s why our team at MarkedUp is excited to be doing what we’re doing

We’re going to update the statistics daily and help developers track how quickly Windows 8 is picked up by the community at large, using our entire data set.

Sampling Methodology

Our methodology for sampling the data displayed in the charts is straightforward: we take a seven day rolling average of all active users and new installations detected from an app and calculate rate of change between them.

There are some other things we do to try to prevent outliers from spiking the graph (i.e. apps that acquire a large number of users rapidly, usually popular titles ported from other platforms) but generally it’s all just rate of changes against a moving average of new devices activated and daily active users.

You’ll notice a big surge on the 19th – that’s due to a trend that started on the 15th of October where the Windows Store approved nearly 20% of the current apps that are in market now (roughly 5000 apps in market,) which subsequently lead to a big surge in our numbers.

If the Windows Store goes through another sustained round of high-volume approvals that will similarly spike our numbers again.

We’re working on refining our methodology for the “Windows 8 by chipset architecture” graph at the bottom since we expect it to change radically with the availability of new ARM devices.

Overview

In Windows 8, Windows Store (formally known as metro style) apps have the ability to define background tasks that can perform tasks that run even when the app isn’t in the background. Though to make sure the user’s battery doesn’t cry uncle prematurely these background tasks are resource constrained. In this post we’ll take a look at how Windows 8 does resource management for background tasks.

The Constraints

Windows 8 performs resource management for background tasks through the use of resource constraints. There are two main types of constraints a background task needs to worry about: CPU time and network usage. The amount of CPU time and network usage an app’s background task is allocated depends on if the app is on the lock screen or not.

A Windows Store app is considered a lock screen app if it occupies one of the seven available lock screen slots on the lock screen.

When your app is a lock screen app Windows will give your background tasks a higher quality of service over resources then a non-lock screen app. The CPU time constraint is enforced regardless of the current power state of the device but the network usage constraints only come into play when PC off of AC power.

Note: Windows will dynamically adjust the network usage constraint based on the power usage of the active network link. Typically, Wi-Fi connections use less power than the cellular connections and will be allowed to send more over the link over a given period of time than cellular connections.

The Elite

Among all the possible triggers available to an app to trigger their background tasks the following triggers are considered “critical” as far a Windows is concerned.

Push notification trigger

Control channel trigger

These triggers are meant to be used during real time scenarios like receiving a VOIP call. These background tasks are given guaranteed app resource quotas according to the resource quotas listed previously. Meaning Windows will not try and terminate these tasks early even if the system becomes resource constrained. These triggers require an app to be a lock screen app in order to be used.

The Hook

If your app doesn’t require the increased resources or trigger capabilities of a lock screen app you’re better off sticking with triggers that don’t require lock screen capabilities. It’ll simplify things but from a programming and certification standpoint and from a user standpoint in terms of battery life.

If you do require lock screen capabilities for your background tasks here’s what you need to know. To be on the lock screen you’ll need to provide an additional image asset, a 24 by 24 pixel png image, for the badge that gets displayed on the lock screen. As there are only 7 slots available on the lock screen for apps you’ll be competing with other apps for those slots so you’ll have to make a compelling case to the user to add your app. Which brings us to our next point, the app will needs to be added to the lock screen explicitly by the user.

That last point is key, there is no programmatic way to add an app the lock screen. Windows does toss the app a bone by giving a way for the app to programmatically ASK the user to add the app to the lock screen though the BackgroundExecutionManager.RequestAccessAsync() method but it comes with a big caveat. It’s a one shot deal. No matter the outcome: yes, no or dismissed it will only work once.

How do I make users aware that my app exists? That’s most likely one of the most prominent questions a developer’s ask themselves when they release an app, and for good reason. No one likes to see their hard work go to waste. A little known feature in Metro IE is its ability to advertise the availability of Windows Store app (also known as a Metro style app) for the current website in the Windows Store though Metro IE’s appbar.

Metro IE allows a website to specify the following actions for an app:

Install an app if it’s not already installed

Switch to an app if it’s already installed

A website can choose to have just one of the options active or both depending on their needs. The way Metro IE recognizes a website has an associated Windows Store app is through the use custom meta tags in the header area of a website’s page.

The minimum required meta tags to light this up are:

msApplication-ID

msApplication-PackageFamilyName

Both of these can be found in the app manifest of the project once the app is associated with store though Visual Studio and are used to link the website and Windows Store app together.

When an app is launched though Metro IE in this manner a custom argument can be specified through another meta tag with the name “msApplication-Arguments”. The app can then read this argument from the OnLaunched method in App.xaml.cs.

As actions speak louder than words, if you want to see this behavior in action you just visit Relay’s website in Metro IE and give it a try. For context, Relay is our sample notification app, feel free to give that a try too while you’re at it

The Bing homepage also has this integration setup if you want to see another live example.

If you haven’t been living under a rock for the past year you’ve at least probably heard about the new C# async and await keywords coming in C# 5 that’s shipping in with Visual Studio 2012. In a nutshell what the feature allows you write asynchronous code and make it look like it’s synchronous. That means that you no longer have to write callback handlers to handle what happens when the async operation you invoked has returned. An illustrative example using good old HttpWebRequest should drive the point:

In this first example we used the traditional Begin/End async pattern on HttpWebRequest to request a website and print it to the console. Notice how you have to split your logic between setting up the request and dealing with the result once results come in. In .net 4 this became a bit easier with the introduction of the Task Parallel Library (TPL) and the Task class.

A way you can think about a Task is that it represents a promise of a future result rather than the actual. In other words sometime in the future I’ll have the value you request. What’s nice about this abstraction is that it allows you to combine asynchronous operations into a single operation thanks to since your returning a promise rather than the actual result.

One thing you might be asking yourself at this point is great I can write an async method in one go now by return a promise of something to come. What if I need to act on the result before I return it to the caller? Glad you asked! And that’s where Task continuations come in. They basically allow you to specify an action to take on a Task once it completes. So enough talk, let’s see this stuff in action:

There are a couple things going on here but take note that unlike with the begin/end async pattern everything is neatly contained within a single method with a Task being returned that will contain the async result being returned.. Let’s break this down starting off with the call to the Task.Factory.FromAsync method. FromAsync is a static method provided by the TPL base class library for bridging the traditional async begin/end pattern over to the new Task based async pattern. The method returns a Task representing the result the begin/end async invocation.

That in and of itself is pretty neat but the real magic of this examples lies in the continuation that’s being defined of the Task we got back from the FromAsync method. All tasks have a method called ContinueWith that then allows you act upon the future result of the Task you call ContinueWith on. Basically, you’re saying what you should do once the parent task or antecedent has completed. No longer do you have to define call backs and event handlers to handle async. You can simple call a method and pass in a delegate. This makes writing async methods immensely easier since your async code is all in one place and reads much better.

The last part is this example is returning the task that was given to us by the call to continue with. This the Task that calling code will wait on for the final result of this asynchronous method. Pretty, nifty right? So now that we’ve seen TPL and Task based asynchrony in action how do C#’s new async and await come into the picture. They make writing and consuming task based async methods so easy that they look like synchronous method calls. No callbacks, no wrapping delegates, events hooks. Just code. (Well it’s all just code in the end but you get my drift).

Seeing is believing so here’s what are method looks like with async and await.

Like I said, just code The interesting to point here are the introduction on two new keywords. The async keyword in the method signature and the await used in front of the methods that have async at the ends of their names. The async keyword marks a method as being asynchronous and allows the use of the await keyword within it.

The await keyword is the bread and butter of all this. What it does in a nutshell is unwrap a Task by introducing a point of asynchrony into the method at which the compiler can logically pause code flow execution until the Task completes. Point of emphasis here “logically pause” code flow execution. Note I didn’t say block but pause.

One thing to be aware of when writing task based methods with async and await is that the method returns after the first await in the method. Which could or could not be what you want. On WinRT and asp.net the thread is released to do other work and will reschedule itself once the Task that is awaited on completes and continue execution after the await. If you try and await on your main method (in actuality you’ll get compile error, but work with me) in a console app you’ve now released your app’s main thread and the program will terminate. Point of this being while async and await do make async work easier to manage you do still need to be aware of their nature.

Hopefully, this you’ve found this high level overview of async and await at least somewhat helpful. But we’ve only just scratched the surface of what the TPL is capable of. We have yet to talk about CancellationToken that help provide unified cooperative cancellation, scheduling of Tasks with the TaskScheduler, concurrent collection primitives like ConcurrentBag and ConcurrentQueue and many more. One last thing parting gift I’d like to leave you with is that if you’re still on .net 4 you can still leverage the async and await keywords in your app. Since async and await are really just a compiler transform all you really need is the C# 5 compiler in Visual Studio 2012 and the set of supporting types which the C# team has made available to .net 4 developers as Nuget package which you can find here.