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'.

None of that wishy-washy My First Multitasking that many other platforms employ because they're all server-class operating systems shoved into a mobile device, but the real deal, made possible because of QNX' embedded origins and focus

Are you serious? In what way is Android's multitasking wishy-washy (whatever wishy-washy means)? In what way is QNX going to make it any better? What could you do with PocketPC that you cannot do with Android? Just why Server Class Operating Systems are going to multitask worse than an Embedded OS?

If I can speak for myself... The fact that Android and iOS can randomly close background apps at any moment, without having their state swapped out to mass storage first, is a major design mistake. If QNX can manage to avoid this outcome in some way, it will already have done mobile multitasking a favor.

And it is also true that anything Linux, NT or BSD-based tends to be quite bad at task prioritization, with things easily getting sluggish as soon as some combination of heavy processing and disk IO is going on in the background. The very reason why RTOSes like QNX exist is so as to avoid this kind of issues, because car brakes cannot afford to respond more slowly when the onboard GPS is busy updating the onscreen map...

If I can speak for myself... The fact that Android and iOS can randomly close background apps at any moment, without having their state swapped out to mass storage first, is a major design mistake. If QNX can manage to avoid this outcome in some way, it will already have done mobile multitasking a favor.

I am sure that is by design. If the OS makes no guarantees that it won't forcibly close your app if it needs the resources for apps and tasks in the foreground, or indeed guarantees that it will forcibly do so, then developers will not be tempted to code apps that need to be run in the background. At least those paying attention won't be.

I am sure that is by design. If the OS makes no guarantees that it won't forcibly close your app if it needs the resources for apps and tasks in the foreground, or indeed guarantees that it will forcibly do so, then developers will not be tempted to code apps that need to be run in the background. At least those paying attention won't be.

It's not even about running in the background, but about conserving the state of apps that stay resident there, running or not.

On Android and iOS, it regularly happens to me that I am doing something in app A, when an SMS or mail kicks in, requesting me to take some action in apps B, C, and D. Then, when I try to get back to my previous activity, I have the displeasure of finding app A restarting, all data about my previous activity being lost.

This should not happen. The minimum when an OS destroys useful app state is to display an apology informing the user about it, rather than childishly try to hide the fact under the carpet. And when the resources that are needed to do otherwise are available, killing should probably be avoided altogether.

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.

Android is designed from day One to keep the state of applications frozen when they are kicked out, so they can be revived later with their memories intact.

The application has to cooperate in selecting what it absolutely needs to remember before being frozen (like, the browser might get by with something like the current URL and a position in it, rather than the many megs taken up by the rendered page). I am sure BBOS10 will do much the same, with much the same limitations.

Huge applications like comples games might have a hard time being minimized, and might be thrown away completely when their resources are needed. Or not, that depends on their design. That might be what you experience as "bad multitasking", but there is no easy way around it.

Other than that, the OS can shove the entire address space of a frozen app to mass storage, but that will fill up mass storage very fast, will be very slow, and will probably eat up a lot of battery, and still the app must be designed to be stopped and restarted at any time.

When free resources are gone, used resources must be freed. If the user does not do it himself, the OS has to choose. Once it has disposed of the dispensable (by letting the app choose what to keep), it will have to dispose of the indispensable (by killing old apps in the background).

So, I don't expect much advancement in BBOS10 multitasking. What's done in Android (and possibly in Winphone) is close to the best you can do when you have little or no virtual memory and you don't want to force users to close their applications manually whenever they finish working with them.