Platform Architecture, Multitasking, and User Experience

There's a bit of confusion circulating around what form background processing or "multitasking" exists in on Phone 7 Series. A distinction needs to be made about multitasking at the OS level, background processing from the point of view of a standard marketplace-installed application, and multitasking as presented to the end user. To fully understand the situation, we need to talk about the software architecture. Let's dive into the details.

In the new-age of smartphone operating systems, WP7S' software architecture is completely unfamiliar. This is the managed, sandboxed architecture common to both iPhone OS and Android thus far. Gone are the close to metal compiled executables known to Windows Mobile developers. This time, virtually every experience runs atop either Silverlight or XML frameworks, or as HTML/JavaScript in the browser (though web-applications are still largely a cop-out).

WP7S' Software Architecture

First off, WP7S itself is a fully fledged multitasking operating system. Applications are called "sessions," and inside each session are other processes, called "pages." WP7S uses a state-based model to allow pages to be restored to the state they were at previously. When you leave a particular page or session, WP7S generally leaves the process running, until the dominant page with focus requests resources that require the old page to be terminated. At this point, the state of the prior page is saved temporarily. This process is called "dehydrating" the application. When you return, the page is "rehydrated" with the state data from before, allowing you to return:

But the other side of the story is that a select number of first-party applications are allowed to be persistent, and truly run in the background. These are specific use scenarios that have been highlighted which Microsoft believes make sense. Those include loading a website in the background, playing music from the first party Zune music player, and allowing the phone to continue in the background. Other third-party applications, however, can be killed after suspension.

So the WP7S platform itself supports simultaneous process multitasking, but not for marketplace-installed third party applications. It's as simple as Charlie Kindel put it, "in this release, you cannot write code that will run in the background." So although multitasking is there, it isn't something that will be made accessable to third party developers. If you don't believe me, check out this demo screenshot from Istvan Cseri's awesome WP7S architecture deep dive presentation:

Two sessions, three pages, all running. Multitasking is there, you just can't use it. Yet.

It's even more compelling to see it in real time:

I asked Istvan after his demonstration flat-out whether there was any way that third party devs could enable multitasking for their programs. Be that setting a flag for persistent background execution, obtaining certification through additional marketplace vetting, or a lightweight executable. Pandora has become the perfect example of the kind of multitasking users pine for; streaming radio running in the background, with the same persistence as the first-party music player. I asked whether this use scenario would be possible on the WP7S platform scheduled for release holiday 2010. The answer was as clear as it was disappointing: no.

So you're probably wondering, why can't third party developers write applications that run persistently in the background? For now, it's because Microsoft isn't sure how to allow it without the potential for battery-draining to happen. Power users like AnandTech readers are able to make the distinction between a dead battery caused by the platform being poorly written, and poor battery life caused by running an application in the background. But ultimately, Microsoft is worried that your average end user won't see the distinction, instead faulting the entire platform as having poor battery life and power management.

Charlie Kindel, Microsoft's leading Windows Phone 7 Series evangelist, shared an anecdote several times about how a leading competitor's phone allowed for implicit multitasking (leaving applications running unless explicitly closed) which led to a poor end user experience, and dead battery for his daughter.

If you've ever used a Windows Mobile phone, you're probably completely familiar with that scenario. And it goes beyond just battery life; there's also the question of how best to allocate resources when other things are using CPU cycles and memory in the background. That kind of gradually-degrading performance is another Windows Mobile-ism Microsoft is dead serious about not letting happen. There's also the fact that existing SoCs are barely powerful enough to make running a single application feel quick. It won't be until we get multicore Cortex A9 or Intel Moorestown class hardware before we have the horsepower to multitask without a tangible performance impact.

I pitched an idea to Andre that he seemed receptive to while we talked about the reaction tech community had to the no third party multitasking announcement. As it stands now, multitasking isn't being included almost entirely as a design decision; Microsoft wants to get it right the first time so that the end user, out-of-box experience isn't like the one Charlie Kindel's daughter had. Its concern is that the lowest common denominator of users will attribute the rapid decrease in battery life to a platform or hardware problem, not just the sad reality of how quickly constant radio traffic and access to the audio stack can drain the battery.

What I argued is that users need to be empowered to make the decision between unitasking and multitasking themselves. They need a clear and obvious visualization about what the current power demands on the hardware are, and a prediction of how long the device will last based on that current use scenario. The analogous comparison is so obvious, I'm surprised nobody has made it yet: the laptop. For years now, users have been given direct control over whether they want to sacrifice battery life for performance, or performance for battery life. The obvious next step is to both extend this profile-based decision making to the mobile phone, and the problem will solve itself. I argue that if notebook users can do it and fully comprehend it, mobile phone users can as well.

Users already are forced to shape their expectations for both call quality and data throughput based on cellular signal visualizations (a far more nebulous metric than an unambiguous power report from the hardware). I argued that this same visualization and feedback should be passed onto the user for battery life and power draw so they can shape expectations and make decisions about what's best for them. Andre said he'd pass my thoughts on. It could be that this generation of ARM hardware doesn't have the metal taped-out to report power use in realtime, but in time, its offerings (and offerings from intel) must. Even then, it isn't as simple as enabling power reporting on the SoC, carriers think they know what's best for the user and are eager to value-add with their own performance and battery targets. It will be an uphill battle to wrangle control out of their hands, and into users'.

Will Microsoft support Unicode in its WP7S phones? They never got around to it on the Zune. I hope they do for WP7S and hopefully in Courier. It's easier to read text the way it's meant to be read than in gibberish ascii with diacritics. Reply

The article says, "There's also of course the stigmata attached to buying a phone preloaded with a bevy of carrier-branded applications."

The author should have used "stigma" rather than "stigmata". Stigmata is a Roman Catholic reference: (from dictionary.com) marks resembling the wounds of the crucified body of Christ, said to be supernaturally impressed on the bodies of certain persons, esp. nuns, tertiaries, and monastics. Reply

Applications can't currently run in the background, but they can process push notifications. Does this mean that any application that wants to provide background processing needs to wake the phone via push notifications? If so, do those mean that the push notifications need to come through a Microsoft back-end notification server? If so, that would be another case of application lockdown. I can't see Facebook or Twitter wanting to run their traffic through Microsoft just to be able to use the notification service. Reply

Is it perfect? Nope but i still think its pretty dang good. Can't wait. I will still probably get a nexus one when it comes out tuesday but will get a wp7 near xmas. Have a BB Tour now and i hate it with a passion. If your not an email addict then i don't think you would ever like a BB. I'd get a palm pre instead if it didn't sound like they were just about to die. RIM should buy them. Reply

Will the tight hardware requirements allow Microsoft to release upgrades directly to the end users or will they release in to the manufacturers/carriers? Will we be at their mercy for timely upgrades? Reply

Part of the reason Microsoft wants tight control over hardware is so they can focus on other stuff and not write 9000 drivers. Windows CE works on ppc, x86, arm with varying amounts of ram and configurations. It is the same strategy Apple has, only have a few select hardware platforms and focus on the user experience. Reply