Why PalmSource May Be Right About Multitasking

[Bob Russell]

If you've followed any of the discussions comparing Pocket PC and PalmOS devices, you know that the three topics almost guaranteed to come up are:

1. Pocket PC is more like a PC vs PalmOS is easier to use for a handheld
2. Pocket PC has better hardware and multimedia vs PalmOS is just as good
3. Pocket PC has multitasking vs Handhelds don't need that kind of multitasking

These points will continue to be debated ad infinitum, and to be honest it's a lot of fun! But today I want to give a perspective on the third item that I don't think has really been discussed much.

As you probably know, I recently moved from a Toshiba Pocket PC to a Treo 650, and I really like it. But I found myself wishing it had multitasking like the Pocket PC did. Instead of just stopping there, I decided to think it through a little bit further and was surprised at what I came up with.

So I asked myself, "Why do I miss the multiple applications running like in Pocket PC?" For example, Cobalt is supposed to have true preemptive multithreading/multitasking or whatever you want to call it, which is really not so far off from what a desktop OS might do. And it sounds like with PalmOS for Linux, some of the thread and context limitations from the OS may be lifted also. I suppose that the future of Linux kernel, improvements in the Linux kernel, and better hardware CPU support will allow this to become even more robust. It's necessary, I suppose, to handle things like cell calls while doing wifi and bluetooth, and doing various other background computing for whatever reason. But I'm neither an expert on this, nor am I really all that concerned about learning the details. It's all very interesting to me for a moment when a clear explanation is given, and then someone goes and brings up a new angle and puts me back in my natural state of confusion all over again!

But my point is that we need to follow PalmSource's advice and look at what the user sees and needs on a handheld device. Their argument is that you really don't do two applications at once on the screen anyway. You have an application on the screen, and then you may have various other things happening in threads for a toolbar, an mp3 player, a pop up window activity, etc. If you really go to another application the screen switches, and you really don't need to know whether or not that first application is still runnning or not. You just want to be able to go back to it when you choose to.

Aha! That's the whole problem, isn't it?!

Here's why I say PalmSource may be exactly right about multitasking. They are completely right in this regard -- While we need background processes, we really don't care whether or not we have a bunch of screen-filling applications running at once if we are only using one at a time. In fact, managing what programs are running on Windows Mobile is one of the biggest annoyances leading to a third-party essental utility as an add-on to keep you from throwing the device out the window and hitting your neighbor in the head!

But, somehow, we haven't seen that PalmSource philosophy come through into the user experience. It has become more of a justification for the way PalmOS works than the basis for a good user experience.

Let me describe what I mean by going back to what I miss about Pocket PC. I could (with Wisbar Advance) pop up a task list and easily switch to any running application. So the ones I use back and forth can be switched easily. I didn't care if they continued to run, I just wanted to be able to continue using them. I also liked continuing to use them in the same state that I left them in. Not a problem if they are still running.

So it's not a multitasking issue, it's a user interface issue. And I think both Windows Mobile and PalmOS have kind of blown it so far. I'm sure they will both get better, but Windows Mobile shouldn't require an add-on to easily handle program switching and program closing. It's a headache to the user, and that's what good design is supposed to avoid, right?

And with PalmOS, you shouldn't have the messy program switching that you experience. For example, on my (delightful!) Treo650, if I put an mp3 on pause from RealPlayer and switch to another application, then when I come back my track starts at the beginning again. It remembers my track, but not my position in the track when I paused it. According to what I learned in a programming class for PalmOS, that isn't how it's supposed to work. The user isn't supposed to know that the application had to restart and didn't just keep running. But the problem is that I was inconvenienced by it.

Another example of how the UI can be a bit of a nuisance is when, for example, I'm happily reading something in iSilo. Then I remember something that I need to do. One of the great things about a pda is that when you remember something you can record it right on the spot and forget about it. So I go to the Tasks application to enter my todo item. So far so good. But on PPC, I can then go back to iSilo easily. Not so much because it's still running, but because there's a drop down menu that has it still listed assuming I didn't do something special to force it to close. So on PPC I just tap tap and I'm reading again. But with PalmOS (and no add-on software), I have to go to home, find iSilo and launch it. It might not seem a big deal, but for a core and common sort of action it can be a bit of a nuisance.

Now don't get me wrong... it's not a big deal. It's easily solved for the most part by picking the right apps or adding third party software. And this is not meant to be fodder for people to say "I told you PPC/Palm was garbage!"

But my point is that it's the UI that's the real issue in this Palm vs PPC fight over multitasking, not the technology or philosophy of the OS. I'm pretty sure that both OS's are actually quite capable. And the good news is that the UI is certain to improve quickly in both camps.

[derekweb]

Good read, and worth the time. Thank you. Thinking it thru, it makes sense too. Again thank you.

[Alexander Turcic]

Great editorial Bob... as always!

There is one instance, at least for me, where multitasking (and perhaps a fast CPU) becomes important even with handhelds: Internet connectivity.

I daily check RSS feeds with NewsBreak on my PDA. And I am not talking about 5 feeds here. I think I have around 100-150 feeds added to NewsBreak. Downloading all of them can take some time. With multitasking, I easily switch to another application, let's say iSilo, to read another chapter of my current e-book. Few minutes later I switch back to NewsBreak, and Voila!, have all feeds updated.

Another example: When I browse the web using NetFront or PIE, and may decide to download a larger file to my 2GB SD card, I don't have to wait until the download is done. Even if the download is 100MB big, I can easily switch back to reading my e-book or studying my stock market application without starring at the download process bar for half an hour.

Third example: At all the the time, I have an IMAP connection open to my e-mail account. When new mail arrives, I get immediately notified, even, for instance, if I am reading an e-book in that moment.

Not to mention GSPlayer, which is constantly running in background streaming live music from an Internet radio station.

You see, I agree with you that in the normal sense and for what PDAs were meant to be multitasking is not of intrinsic importance. But if you are like me who likes to do several things at once (yes, even we men can do that sometimes!), being able to switch applications without stopping them can be a real blessing and a time-safer!

As for the UI changes... I am disappointed that Microsoft's WM 5.0 almost looks identical to 2003 SE. I have much greater hopes that in this regard PalmSource will do something revolutionary with the first Cobalt releases ("Project Rome").

[Bob Russell]

Thanks Alex!

Regarding the examples you gave, I might be wrong, but I think that PalmOS for Linux (and probably Cobalt already) supports all those things very well. Preemptive multitasking capability is built in, just probably not the same way it's done in Windows Mobile. And I am pretty sure that you have named exactly the kinds of things PalmOS was built to handle.

If you think about it, these things don't sound very different from what you see right now with background Real Player while reading an ebook... which is even part of Garnet. With Garnet it probably takes a "cooperative" application willing to play nice, but with Cobalt, the OS is more in control.

And remember that there may also be issues with multiple radio operations. I think until the LifeDrive, you couldn't do wifi and Bluetooth at the same time on a Palm device, for example. And it's up to the application to restart in the state you want it to restart in, so I don't think that's an OS limitation.

Maybe someone that know the details better than me can clarify?

[hacker]

Palmsource didn't decide to nix multitasking from their OS... they were limited BY LICENSE from exposing more than 1 thread to the OS from the underlying kernel (they licensed the AMX kernel from an embedded company called KADAK in the early Palm days when they were still called 3Com, and kept with that single-thread model through 3 other kernel rewrites that they undertook).

The terms and conditions of that license specifically state that Palm may not expose the API for creating/manipulating tasks within the OS. If you need access to these calls you need to contact Kadak at (604) 734-2796, or visit their website at http://www.kadak.com

So they could have easily implemented it, but their license agreement with the kernel manufacturers restricted them from doing it. The kernel itself is multithreaded, multitasking (at the hardware level), but not exposed to the OS.

Most of these "limitations" are never technical in nature.. and this is no exception.

[macrotor]

I've been in this conversation before, and you're right: it's fun to debate!

Personally, I see multi-tasking as a kludge to make up for sloppy programming (oooooh....I got a GOOD reaction from a PPC-zealot on that remark)! Take your example of Real Player: if it would properly return in EXACTLY the same state you left it, you would see NO difference between between task-switching versus multi-tasking. But, many developers don't put in the extra effort to do it right, and Palm suffers for it.

With multi-tasking, the program always runs, so the developer can be lazy about such things. However, this is a waste of processor power. I rather like how I can bounce between 4 different apps on the Tungsten C without experiencing a slow-down within each app. Things start getting a little sluggish on the PPC if you don't manage your tasks properly.

Solution? Not sure on that one. I suppose Palmsource could try to improve the developer tools so that "state-saving" is easy to implement, but developer-laziness can always overcome that.

For me, I use Zlauncher with QuickLaunch so that my recently-used apps are quickly available (like a taskbar), and then select applications that state-save properly. It's the best of all worlds, if you can find the good apps.

But, I'm sure the developers prefer the PPC Multi-tasking for ease of development.

- Jim

[Dianne Hackborn]

Hi Bob!

I very much agree with you on this, including the fact that Palm OS (including Cobalt) still hasn't really done anything to address the issue.

Dealing with multiple concurrent activities on these devices, at the user level, is something that we think is going to be one of the key things that needs to be dealt on the devices that are now starting to appear. In fact, phones are already starting to run into the complexity it causes, and in my opinion for the most part punting on it. As 3G gets more widespread, we think this is simply something that will have to be addressed in order for the average person to use the new features it makes available.

For PalmSource, Cobalt was basically the necessary first step needed to get the OS infrastructure in place to deal with this stuff, but very little was done in the UI. In fact, the slips in Cobalt are one of the very early UI efforts we did to start dealing with it -- the basic concept of the slip being a little mini-application that can run independently of the main application flow. However, I would really say as it stands they only barely start to help.

I have a few specific replies to your comments:

Originally Posted by BobR

And it sounds like with PalmOS for Linux, some of the thread and context limitations from the OS may be lifted also. I suppose that the future of Linux kernel, improvements in the Linux kernel, and better hardware CPU support will allow this to become even more robust.

For the most part, I think the meat of the issue is in the way the UI works: Cobalt, Windows, Linux, and Symbian all have the basic kernel and system support to be able to do what is required. The real challenge is in figuring out how these features are exposed to both the user in the UI they experience and to application developers in how they write their applications.

Originally Posted by BobR

For example, on my (delightful!) Treo650, if I put an mp3 on pause from RealPlayer and switch to another application, then when I come back my track starts at the beginning again. It remembers my track, but not my position in the track when I paused it.

As it happens, the Cobalt media player will remember your track -- and in fact, if you switch to another application while playing a song, it will continue playing in the background without a hiccup. The media system accomplishes this by running the media playback functionality in our background process. The media player app itself is really just a remote control for the media playback thread that is left running. You can, of course, also structure your application so that it runs all of its UI from the background process and "switching" to it just involves telling your background thread to bring up its UI. This is probably the way you would want to do things like web browsers.

Btw, the same MediaPlayer behavior applies to watching videos as well listening to audio, except I believe the media player will normally pause a video while it is not running as the main app.

Originally Posted by BobR

Another example of how the UI can be a bit of a nuisance is when, for example, I'm happily reading something in iSilo. Then I remember something that I need to do. One of the great things about a pda is that when you remember something you can record it right on the spot and forget about it. So I go to the Tasks application to enter my todo item. So far so good. But on PPC, I can then go back to iSilo easily. Not so much because it's still running, but because there's a drop down menu that has it still listed assuming I didn't do something special to force it to close.

I don't know if this exactly addresses your need, but on Cobalt if you hold down on the Launcher/Home icon in the status bar, you will get a pop-up menu of the recent applications you have run, allowing you to switch back to one without going through the Launcher. I don't think the overall UI is all that great (it is not at all obvious you can do this, and having to press and drag as the only way to access this functionality kind-of sucks), but it's a start.

[surur]

In the Multi-tasking vs Saved State debate, the fact is, one is better than the other one, and for a number of reasons.

Multi-tasking is better of course because:
1) It encourages the use of a robust OS with proper memory space protection, meaning its less easy for a rouge application to take your device down. If there is only one program running at a time then you do not need these special measures.
2) It removed the burden for the UI from the developer to the OS, meaning good software is easier to right, meaning more and better software, which benefits the end user.
3) Returning to a saved state has its own costs, and may not necessarily be instant e.g. re-paginating an ebook, re-rendering a web page or acrobat file, re-calculating a formula etc, loading a file from slow storage back into memory etc.

Thats regarding saved states. I believe in a way you are confusing saved states vs multi-tasking also. Clearly playing music in the background IS multi-tasking, as is running an IM program. Saved state as you described above is NOT. So the other difference between PPC's and Palms is the TYPE of multi-tasking, that is pre-emptative vs cooperative.

Pre-emptative is better, again for stability and robustness reasons, which is as useful on a PDA as on a desktop. In many instances, when software crashes on a PPC you are returned to the desktop. In Palm it resets the device. They are less stable and more fragile because of cooperative multi-tasking. The implementation is also very dependent on software developers, and if they mess up your device is toast.

Palms use a combination of cooperative multi-tasking and saved state. The Real Player on Palm is a good example of software that does multi-tasking (playing music in the background) but did not do the saved state properly. This imposes a burden on developers, meaning they spend more time coding around the deficiencies of the OS and less doing the real work of the software. It introduced additional complexity into every program, instead of just in the OS where it can be perfected and used by all the software. Maybe this is why PPC software is generally better than POS software.

I agree than PPC's could do a better job at exposing the multi-tasking, like a desktop taskbar does, but this is the only way their model is deficient. Lets stop acting as if we are constantly restrained by resources. We are no longer dealing with 33Mhz devices and 2 MB memory.

Surur

[Dianne Hackborn]

Originally Posted by hacker

Palmsource didn't decide to nix multitasking from their OS... they were limited BY LICENSE from exposing more than 1 thread to the OS from the underlying kernel... Most of these "limitations" are never technical in nature.. and this is no exception.

While that was true at one point, Garnet actually uses a kernel that was developed in-house by Palm. In fact, the Garnet kernel is an early version of the kernel that was done for Cobalt.

One of the issues is that there is a lot more to multithreading than just having the kernel functionality. For example, though you (well we and our licensees) could spawn a bunch of threads on Garnet, there is very little those threads could actually -do-. None of the UI system in Garnet was thread-safe, so nobody except the single main application thread could do any UI at all. I don't other parts of Garnet all that well, but I don't think there were many other things the threads could do -- there were probably even limitations on what IO operations could be done.

When I got to Palm, Cobalt kernel and lower-level services were basically up and working... then we spent the following two years making the rest of the system actually able to take advantage of them.

[dwig]

Originally Posted by surur

In the Multi-tasking vs Saved State debate, ...
2) It removed the burden for the UI from the developer to the OS, meaning good software is easier to right, meaning more and better software, which benefits the end user.
...
Surur

But it must be kept in mind that better applications only benefit the user if they come without the burden of a less stable OS. The net benefit to the end user is not clear when comparing the integrated whole application+OS.

In reference to BobR's original discourse, I''ve found that for my use the Sony applets added to PalmOS5 in the UX series provide all of the application switching "fixes" that I need, particularily the CTRL-Num app launching functions. That is, providing my applications successfully "remember" where I left off. I use MobiPocket as my common eBook reader and it does a good job as do the majority of the applications and PIM applets that I use on a daily basis.

[surur]

New pocketpc's are more stable than new Palms, and it takes less effort to make them stable also.

http://www.1src.com/forums/showthread.php?t=90438

Surur

[hacker]

Originally Posted by surur

New pocketpc's are more stable than new Palms, and it takes less effort to make them stable also.

Who cares if they're more stable, if they're less functional?

Also, it shouldn't take any "effort" to make something stable. You're a user of the device. It should be stable by default. If it isn't, its broken. Find another vendor.

[Alexander Turcic]

If you can have multitasking then why not? Multitasking doesn't mean that programs necessarily have to continue running in background if you don't want to. But you get to choose. For instance, Betaplayer has options that allow you select whether you want audio, or video, or both stopped when switching to another process.

[Voice_of_Reason]

Originally Posted by BobR

If you've followed any of the discussions comparing Pocket PC and PalmOS devices, you know that the three topics almost guaranteed to come up are:

1. Pocket PC is more like a PC vs PalmOS is easier to use for a handheld
2. Pocket PC has better hardware and multimedia vs PalmOS is just as good
3. Pocket PC has multitasking vs Handhelds don't need that kind of multitasking

These points will continue to be debated ad infinitum, and to be honest it's a lot of fun! But today I want to give a perspective on the third item that I don't think has really been discussed much.

As you probably know, I recently moved from a Toshiba Pocket PC to a Treo 650, and I really like it. But I found myself wishing it had multitasking like the Pocket PC did. Instead of just stopping there, I decided to think it through a little bit further and was surprised at what I came up with.

So I asked myself, "Why do I miss the multiple applications running like in Pocket PC?" For example, Cobalt is supposed to have true preemptive multithreading/multitasking or whatever you want to call it, which is really not so far off from what a desktop OS might do. And it sounds like with PalmOS for Linux, some of the thread and context limitations from the OS may be lifted also. I suppose that the future of Linux kernel, improvements in the Linux kernel, and better hardware CPU support will allow this to become even more robust. It's necessary, I suppose, to handle things like cell calls while doing wifi and bluetooth, and doing various other background computing for whatever reason. But I'm neither an expert on this, nor am I really all that concerned about learning the details. It's all very interesting to me for a moment when a clear explanation is given, and then someone goes and brings up a new angle and puts me back in my natural state of confusion all over again!

But my point is that we need to follow PalmSource's advice and look at what the user sees and needs on a handheld device. Their argument is that you really don't do two applications at once on the screen anyway. You have an application on the screen, and then you may have various other things happening in threads for a toolbar, an mp3 player, a pop up window activity, etc. If you really go to another application the screen switches, and you really don't need to know whether or not that first application is still runnning or not. You just want to be able to go back to it when you choose to.

Aha! That's the whole problem, isn't it?!

Here's why I say PalmSource may be exactly right about multitasking. They are completely right in this regard -- While we need background processes, we really don't care whether or not we have a bunch of screen-filling applications running at once if we are only using one at a time. In fact, managing what programs are running on Windows Mobile is one of the biggest annoyances leading to a third-party essental utility as an add-on to keep you from throwing the device out the window and hitting your neighbor in the head!

But, somehow, we haven't seen that PalmSource philosophy come through into the user experience. It has become more of a justification for the way PalmOS works than the basis for a good user experience.

Let me describe what I mean by going back to what I miss about Pocket PC. I could (with Wisbar Advance) pop up a task list and easily switch to any running application. So the ones I use back and forth can be switched easily. I didn't care if they continued to run, I just wanted to be able to continue using them. I also liked continuing to use them in the same state that I left them in. Not a problem if they are still running.

So it's not a multitasking issue, it's a user interface issue. And I think both Windows Mobile and PalmOS have kind of blown it so far. I'm sure they will both get better, but Windows Mobile shouldn't require an add-on to easily handle program switching and program closing. It's a headache to the user, and that's what good design is supposed to avoid, right?

And with PalmOS, you shouldn't have the messy program switching that you experience. For example, on my (delightful!) Treo650, if I put an mp3 on pause from RealPlayer and switch to another application, then when I come back my track starts at the beginning again. It remembers my track, but not my position in the track when I paused it. According to what I learned in a programming class for PalmOS, that isn't how it's supposed to work. The user isn't supposed to know that the application had to restart and didn't just keep running. But the problem is that I was inconvenienced by it.

Another example of how the UI can be a bit of a nuisance is when, for example, I'm happily reading something in iSilo. Then I remember something that I need to do. One of the great things about a pda is that when you remember something you can record it right on the spot and forget about it. So I go to the Tasks application to enter my todo item. So far so good. But on PPC, I can then go back to iSilo easily. Not so much because it's still running, but because there's a drop down menu that has it still listed assuming I didn't do something special to force it to close. So on PPC I just tap tap and I'm reading again. But with PalmOS (and no add-on software), I have to go to home, find iSilo and launch it. It might not seem a big deal, but for a core and common sort of action it can be a bit of a nuisance.

Now don't get me wrong... it's not a big deal. It's easily solved for the most part by picking the right apps or adding third party software. And this is not meant to be fodder for people to say "I told you PPC/Palm was garbage!"

But my point is that it's the UI that's the real issue in this Palm vs PPC fight over multitasking, not the technology or philosophy of the OS. I'm pretty sure that both OS's are actually quite capable. And the good news is that the UI is certain to improve quickly in both camps.

I'm afraid you don't really seem to understand the true advantages of multitasking. At the same time you're also needlessly criticizing a UI deficiency in PalmOS that is easily remedied.

The following thread may be revealing:

http://www.allaboutpalm.com/forum/sh...?p=161#post161

http://www.allaboutpalm.com/forum/sh...?p=208#post208

http://www.allaboutpalm.com/forum/sh...?p=215#post215


Multitasking is the way of the future because it removes constraints that would otherwise waste a lot of time. The advantages are most apparent in wirelessly connected PDAs, but even unconnected PDAs can benefit from multitasking. The ability to browse the Internet while downloading email, listening to MP3s and copying text at will to a text editor requires "multitasking" (in the simplest meaning of the word). Why would anyone want to do multiple tasks sequentially when they can be done either at the same time or without having to waste time restarting programs?

In practice, the ability to quickly switch between apps conferred by having a multitasking OS is the least important advantage over a non-multitasking OS. The difference in ease of app switching between PPC + WisBar and PalmOS + McPhling is arguably rather trivial. Where PalmOS falls flat on its face is in its (dis)ability to perform tasks concurrently. Constantly stopping and starting apps, disconnecting and reconnecting to the Internet, etc. adds a needless burden to the use of a PDA.

For years I've argued in favor of PalmLinux - a Unix-based platform running Palm apps. Last year Ms. Hackborn berated me on another site for having the temerity to suggest PalmLinux was a good idea. Now it would appear her employer agrees I was right all along. Cobalt is merely a "baby step" in the right direction (towards true multitasking), but Palm/PalmSource has a LOOOONG way to go at this point in time. It sounds like the current (not available in stores near you) version of that legendary OS, Cobalt has some "issues" with memory management and stability. Furthermore, Cobalt's ability to simulate true "multitasking" is limited right from the start by PalmSource's choice of merely a "multithreading" architecture. It appears that Cobalt is little more than a glorified beta version of Palm's long overdue saviour: PalmLinux. The biggest question right now is whether or not PalmSource can solve all of the issues around porting Cobalt to a Linux kernel before their market loses interest completely and moves en masse to an alternate OS. PalmSource has claimed PalmLinux will be ready before mid 2006. I'll believe that when I see it. Because multitasking will soon be an essential OS feature, if Palmsource fails to deliver on its PalmLinux promise it will probably be game over for the platform.

It's interesting to note that PalmSource - a company that supposedly has such UI advantages over PPC - has repeatedly failed to make any improvements to that UI. A tabbed interface (e.g. LauncherX) and rapid app switching (e.g. McPhling) are obvious advances to the PalmOS UI that are still left to third party developers to provide. It remains to be seen if Palm will even provide an intuitive way to cycle between open threads in Cobalt. I've suggested a customized browser-style tabbed UI, or better yet, showing icons of all open applications on the DIA. Now we hear talk of an ambitious UI code named "Rome". Why can't PalmSource just fix the bugs and polish its current OSes before heading off on yet another wild goose chase? The lack of focus and praticality that killed Be seems to "Be" rearing its ugly head again...


TVoR

[Voice_of_Reason]

Originally Posted by hacker

Who cares if they're more stable, if they're less functional?

Also, it shouldn't take any "effort" to make something stable. You're a user of the device. It should be stable by default. If it isn't, its broken. Find another vendor.

How are PPCs "less functional" than PalmOS PDAs? I've argued in the past that PPCs are "less intuitive" (usually lessened with time +/- utilities like WisBar) and "less stable" (now debatable) than PalmOS PDAs, but even I would have difficulty saying a $400 Dell X50v is "less functional" than a $400 Tungsten 5. Unless the PPC UI rendered these devices completely unuseable (it doesn't), functionality ends up being based significantly on included features. And in terms of features, Palm is - to put it mildly - simply not competitive. Not even close. Dual CF/SD expansion, dual Wi-Fi/Bluetooth wireless, user-replaceable batteries, VGA screen... these are specs that make PDAs "more functional". Solly Cholly.

TVoR