The data-driven architecture of Windows 8 helps you run numerous apps at once while maintaining performance and battery life.
These days, just about any PC, laptop or mobile environment has some form of gadget, widget or plug-in model that gives you at-a-glance information. You can watch TV news, sports or weather within a structured screen with many data sources coming together in real time. You expect to be able to quickly check your stocks, weather, e-mail, appointments or even social networking status in a matter of seconds before getting back to whatever else you’re doing.
This translates to a massive drain on performance and battery life. In many ways, you could argue the modern PC has some catching up to do in this area when compared to laptops and other mobile devices. In designing the notifications infrastructure in Windows 8, the challenge was how to make the PC feel alive with activity while continuing to operate efficiently with respect to power and bandwidth usage.
The Windows 8 Start screen makes this type of operation efficient from a user perspective by giving you a full-screen heads-up display without interfering with your desktop or other apps. Besides making it efficient, we wanted to make sure you could install as many notifying apps as you want, without having to worry about the impact on performance or battery life. You can use the Windows 8 Start screen as a unified and highly readable heads-up display for line-of-business (LOB) applications. In this way, it has become a productivity enhancer.
With the scalability of our new push notifications platform, Windows 8 can deliver this capability with minimal system impact. Even the most hardcore desktop-only person will find a lot of value in the Start screen as a centralized, well-presented and controlled notification area that’s just a keystroke away.
Allowing for hundreds of live app tiles while simultaneously ensuring no performance degradation makes it seem like we have contradictory goals. After all, an “activity” by definition consumes resources. Getting a notification from the cloud uses the network. Rendering the notification on a tile uses processor resources. In order to get the design right, we had to stay focused on the goals we started out with:
Based on these goals, the first fundamental architectural decision was that the platform would be data-driven. No app code should run in the background to power the Start screen. If you think about the anatomy of a notification-delivery system, it involves several pieces. There’s logic for when to connect, authentication, local caching, rendering, error handling, back-off algorithms, throttling and so on. The system also has to deal with service-side issues such as knowing when you’re connected. It must be able to cache undelivered content and handle complex scenarios for retrying.
Can you imagine if every single app with a live tile had its own version of all that client/server code? Not only would you have different bugs in each implementation, but duplicates of essentially the same code for each app loaded in memory. That code would be constantly paged in and out to the disk. This would be most inefficient, because all of your apps would be running all the time to keep the Start screen alive. Even on a machine with lots of memory, system performance would eventually grind to a crawl.
Performance degrades as you increase the number of processes, DLLs and services running at once. If each live tile was running with its own code, the goal of allowing hundreds of live tiles without degrading performance would be impossible. The solution was to build a data-driven model.
This means an app developer can express his tile using a set of predefined properties and templates. In this case, it uses an XML schema. The XML tile data is then sent to Windows Push Notification Services (WNS) via a simple HTTP POST and Windows 8 takes care of the rest. All the code for connecting, retrying, authenticating, caching, rendering and error handling is done in a uniform and power-efficient way.
The decision to use a data-driven model helped us achieve the first two goals of performance and a high-fidelity experience. But the challenge of determining how to achieve real-time delivery and fire-and-forget-it efficiency still remained.
There are two high-level design patterns with client/server content delivery—polling and push. Polling means the client checks with the service on a regular basis (for example, every 90 minutes) to check for new content. Push means that when there’s new content, the service sends the data down to the client directly.
The only way to support instant notifications with a polling model would be to poll on a sufficiently high frequency (such as every 5 seconds). That way, if a new message arrived, you’d see it instantly. But doing so would kill the performance level. With a 5-second poll interval, the network radio stack would never be idle, battery life would be horrible and desktop machines would always be powered up.
It would be a little like talking on your cell phone all day long. Your phone’s battery wouldn’t last long. On top of that, it would be extremely wasteful to check the server every 5 seconds for content, as most of the time there would be nothing new. Historically, system tray notifications and desktop gadgets introduced in Windows Vista have used a polling mechanism. With any polling mechanism, though, the interval is still not short enough for today’s real-time services.
That’s why Windows 8 uses a push-based service. This was a big decision because it meant the platform was built at a global scale, eventually powering the tiles for hundreds of thousands of apps and more than a billion people. The value was clear. Developers would get efficient real-time notifications to their customers for free, without having to build or maintain persistent connections to the client.
Let’s take a closer look at the various components of the platform to explain some of the subtler parts of the design. There are three key entities:
Here’s a typical usage scenario to illustrate how this works. Suppose an app service is a social networking site that sends a tile update when someone comments on a photo. This could just as easily be an LOB app that updates you with new assignments or when an expense report needs attention. When there’s an update, the app service sends a notification to WNS.
From there, WNS pushes the notification down to the client. When it’s time to show the tile update on the Start screen, the OS fetches that image from the app service based on the URL in the notification XML. Once the notification and image are downloaded, the app renders the live tile based on the template specified in the XML and presents it on the Start screen.
To make this truly “fire and forget”—and to ensure that developers didn’t have to write complex caching and retry mechanisms for when the PC isn’t connected—we cache one notification per app in the WNS cloud until the next time that PC is online.
As we designed the client platform components, we wanted to ensure everything was engineered for high performance and low power consumption. One of the key parts of this was separating the notification payload from the image payload. A typical notification XML is less than 1KB of data. An image can be up to 150KB. Separating these helped us save significant network bandwidth for scenarios where there’s a lot of image duplication.
For example, the image for a tile might be a profile picture of a friend. Your PC can download this once and have it cached locally. Separating the notification from the image helps us be smart about discarding unused notifications before downloading the image. If a device screen is off, there’s no point in downloading images for tiles that will just be replaced by subsequent updates before the next time the device is used.
Because live tiles and notifications represent a key part of the app experience, it’s important that the communications channel is authenticated and secure. Therefore, Windows 8 uses an anonymous authentication mechanism that uniquely identifies the connection between the PC and WNS. Apps and app services also authenticate when communicating with WNS.
Authenticating both connections to WNS helps protect against live tile update abuse, such as spoofing attacks. The authentication mechanism WNS uses explicitly ties the application and service together. It does so in a way that keeps other applications (or individuals) from sending content to a tile they don’t own. And naturally, all communication takes place over a secure channel.
This works whether or not you’re signed into Windows using a Windows Live ID. Windows 8 is best when you have a connected account, as you’ll have access to enhancements such as app cloud storage; roaming Windows and app settings; and single sign-on to multiple apps. The push notification platform uses an anonymous authentication mechanism, so even if you do sign in with a Windows Live ID, the app developer can’t use the notification pipeline to find your Windows Live ID, system info or location.
The platform has to support an incredibly large number of users and apps. During the pre-beta development phase, we were already sending almost 90 million tile updates per day. The Stocks app is one of the popular test-drive apps from the Developer Preview build. When the Developer Preview was released, we carefully watched traffic coming through the datacenters to monitor the scale-out.
The WNS design is based on the Windows Live Messenger service architecture. In fact, the service part of the notifications platform was built by the same team. Here are a few statistics to give you an idea of the scale of the Windows Live Messenger service today:
To carefully monitor the performance of the notifications platform, we added metrics into the new Task Manager to let you keep track of how much bandwidth the tile platform is consuming for each app. Resource usage for tiles should be relatively low.
In Windows 8, we set out to design a notifications platform that would provide at-a-glance information, without all the performance and battery life concerns that face traditional plug-in and gadget-based models. To that end, every design decision we made was viewed through the lens of performance and battery life efficiency.
To make it easy for app developers to participate, we built WNS so developers could create live tiles without having to write complicated network connectivity code. Because WNS uses standard Web technologies such as HTTP POST, it’s easy for developers to integrate notifications based on their existing Web services.
The result is a notifications platform that delivers at-a-glance information. Yet you can still install as many apps as you want without worrying about the impact on performance or battery life.
Ryan Haveson has more than 15 years of experience leading engineering teams and delivering software and services for some of the world’s most recognized brands, including Xbox and Windows. He was a group manager in the Windows Experience team for Windows 8. He and his team designed and delivered end-user and developer-facing features, including the live tile notifications platform and the new Task Manager. He’s currently leading the engineering systems group at Qualcomm Inc. for the Windows/Windows Phone on Snapdragon division in sunny San Diego. Reach him at firstname.lastname@example.org or at linkedin.com/in/ryanha.