And so, today, RIM announced its Hail Mary - a brand new mobile operating system (well, sort-of new), as well as two new devices. In addition, the Canadian company also officially changed its name from Research In Motion to Blackberry. The firstfewreviews of Blackberry 10 are already out, and it's not bad. The problem, however, is that in the case of Blackberry, 'not bad' could easily mean 'not good enough'.

Windows 8 handles this by putting apps into a suspended state and expecting state saving to go on during that transition.

From there apps are either returned to "Running" state at some point in the future, or killed.

If your app was killed when it next resumes, you load state, if your app was suspended, then there's no need to reload state as it is still resident in memory.

I hope BB does something similar.

That's the idea indeed, though from what I've heard Windows 8 is falling in the iOS trap of stating that "apps can do nothing in the background, save for arbitrary tasks X, Y and Z which we have received hundreds of support requests about". This, in turn, leads to significant UX problems as soon as a user does something unusual, such as VPN services periodically disconnecting themselves unless managed by OS services that are not subjected to arbitrary restrictions. Can you confirm or infirm this?

In place of such draconian restrictions, I would prefer mobile OSs to use better task prioritization and power management algorithms, so that tasks can be left running in the background as long as possible without significant sluggishness and power draw occurring. Technologies such as soft real-time scheduling have been invented for a reason, after all...

Another potential issue which I see in your post is that apps apparently must explicitly implement state saving (as also done on iOS and Android), rather than having it done automatically by the OS (as done when simply committing the RAM of unused processes and libraries to some form of swapfile). From experience, such mechanisms also lead to UX problems in practice : apps do not display the same part of their UI as when they were left, only part of the state is saved, some apps cache all expensive IO data and resume quickly while others take a lot of time to restart after being killed... To sum it up, user-space developers should never be trusted to perform the job of an OS properly, but OSs which ask them to save their state themselves are doing just that.

TL;DR : Unless I'm misunderstood about the way Windows 8 does things, mobile multitasking still needs more work.

That's the idea indeed, though from what I've heard Windows 8 is falling in the iOS trap of stating that "apps can do nothing in the background, save for arbitrary tasks X, Y and Z which we have received hundreds of support requests about". This, in turn, leads to significant UX problems as soon as a user does something unusual, such as VPN services periodically disconnecting themselves unless managed by OS services that are not subjected to arbitrary restrictions. Can you confirm or infirm this?

I can confirm this, but the amount of things they are allowed to do is much more robust.

There are various types of background tasks that fire when a predefined trigger condition is met. Things like "User logs on", "User obtains internet", "AC power is plugged in" And other things like periodic updates as often as 15 minutes.

You can also do background audio and background file upload/downloading and executing a background task when receiving a push notification.

If you need to keep an underlying socket connection awake in the background, you can have up to 7 apps which do this in the background and provide real time communication.

In place of such draconian restrictions, I would prefer mobile OSs to use better task prioritization and power management algorithms, so that tasks can be left running in the background as long as possible without significant sluggishness and power draw occurring. Technologies such as soft real-time scheduling have been invented for a reason, after all...

I don't disagree that there is much to do here. I think its a significant step forward for Windows 8, but it's far from ideal for a variety of scenarios.

Looking forward, I'm sure WinRT will be improved to support a wider range of situations in which background processing is useful.

I'm sure there will always be corner cases that are missed, but I think this addresses a decent number of use cases.

Another potential issue which I see in your post is that apps apparently must explicitly implement state saving (as also done on iOS and Android), rather than having it done automatically by the OS (as done when simply committing the RAM of unused processes and libraries to some form of swapfile).

Microsoft cedes control to the developer because they know best what they'd like to save. Sometimes it isn't necessary to save the entire state of an app if you just need to save a few select values within your UI.

Maybe I just need to save the current page, and the value of a single scrollbar.

Also, it is at the discretion of the developer to determine when the state is stale so to speak. What if the state is saved, and the user doesn't run the app again for a week? That data isn't really relevant anymore.

From experience, such mechanisms also lead to UX problems in practice : apps do not display the same part of their UI as when they were left, only part of the state is saved, some apps cache all expensive IO data and resume quickly while others take a lot of time to restart after being killed... To sum it up, user-space developers should never be trusted to perform the job of an OS properly, but OSs which ask them to save their state themselves are doing just that.

Microsoft takes very seriously the speed to suspend and resume. I think if it takes more than a few seconds on a low power PC you fail certification.

Developers are forced to be mindful of what they save, when they save it.

Personally in my own apps I do a progressive save in which I take advantage of idle CPU time to periodically save non volatile state to the disk. It reduces the amount I need to save at a later time.

Its always a balancing game, and especially when you're dealing with finicky ARM processors which aren't really that fast, you need to be very careful to not make your state saving code a slow path.

TL;DR : Unless I'm misunderstood about the way Windows 8 does things, mobile multitasking still needs more work.

I can confirm this, but the amount of things they are allowed to do is much more robust.

There are various types of background tasks that fire when a predefined trigger condition is met. Things like "User logs on", "User obtains internet", "AC power is plugged in" And other things like periodic updates as often as 15 minutes.

You can also do background audio and background file upload/downloading and executing a background task when receiving a push notification.

If you need to keep an underlying socket connection awake in the background, you can have up to 7 apps which do this in the background and provide real time communication.

(...)

I don't disagree that there is much to do here. I think its a significant step forward for Windows 8, but it's far from ideal for a variety of scenarios.

Looking forward, I'm sure WinRT will be improved to support a wider range of situations in which background processing is useful.

I'm sure there will always be corner cases that are missed, but I think this addresses a decent number of use cases.

Is there also support for "pure" background processing tasks, such as computing a 3D render or encoding a video ? OSs that go the whitelisting route often have issues with this basic scenario, and it is certainly annoying to have to keep staring at a progress bar out of fear that if you hide a productivity application, it will stop doing its job.

Microsoft cedes control to the developer because they know best what they'd like to save. Sometimes it isn't necessary to save the entire state of an app if you just need to save a few select values within your UI.

Maybe I just need to save the current page, and the value of a single scrollbar.

That is true, but it is to be expected that not every developer will bother to go through his whole codebase, looking for every bit of state which he can find, deciding what to save and what not to save, and then centralizing pointers to everything in one place and serializing everything.

In the event when someone would not do that, the OS should provide a reasonably graceful fallback, such as swapping the application's address space out when RAM gets full, and waiting until both RAM and swap space are full before starting to kill off stuff to free up space.

Microsoft takes very seriously the speed to suspend and resume. I think if it takes more than a few seconds on a low power PC you fail certification.

Developers are forced to be mindful of what they save, when they save it.

It seems strange to put strong constraints on suspend times, since it is not something which users actually experience. Sometimes, saving more data right now allows one to resume more quickly later, especially when that data is very expensive to regenerate (typical example being a heavy webpage loaded over an EDGE network connection).

Personally in my own apps I do a progressive save in which I take advantage of idle CPU time to periodically save non volatile state to the disk. It reduces the amount I need to save at a later time.

Then again, if there were no restrictions on suspend times, you could achieve a similar effect in a simpler way by having the "suspending" thread run at a low priority, both from a CPU and I/O scheduling point of view.

The way you do it reminds me of how I'm basically reinventing pre-emptive multitasking on a work project, because the programming environment that we use has a mostly synchronous API coupled with a totally brain-dead multithreading implementation.