Linked by Thom Holwerda on Thu 2nd Jan 2014 19:31 UTC
PDAs, Cellphones, Wireless

The Verge has an interesting story up detailing the various hardware and software prototypes that could have had a future hadn't HP botched pretty much every aspect of its Palm acquisition. Both in features as well as design, the next version of webOS, codenamed 'Eel', looked quite promising, and the hardware designs certainly stand out too.

Sadly, as I stated in my detailed history of Palm, webOS was, at its core, simply not a Palm product. As I wrote:

A cool UI doesn't hide the fact that it's slow and unresponsive. A cool UI doesn't hide the fact that the underlying system is unoptimised. A cool UI doesn't hide the fact that it sucks battery like a there's no tomorrow. A cool UI doesn't hide the fact that the hardware was of appallingly low quality.

A cool UI doesn't hide the fact that the operating system has absolutely nothing to do with what Palm is supposed to stand for.

WebOS probably looked like the bee's knees to someone used to the version of Android and iOS at the time, but having had a long history using PalmOS products, webOS was a total and utter letdown. WebOS was a badly sewn together set of compromises, unfinished parts and shortcuts - and it showed. From The Verge's article, I get the impression that Eel slapped on a new coat of paint and new user-facing features - but that the lower levels and core of the operating system were still very much the same unoptimised mess.

I'm definitely curious what LG's webOS TV is going to be like - it looks nice - but if it's anything like Palm's and HP's webOS products, it won't light any of my fires.

Thread beginning with comment 579840
To read all comments associated with this story, please click here.
Android as an evolution of PalmOS
by hackbod on Fri 3rd Jan 2014 20:04 UTC
hackbod
Member since:
2006-02-15

I could actually make something of an argument about Android being a spiritual successor to PalmOS. There are actually many aspects of Android's design that can either be traced back to the development of a next-generation PalmOS at PalmSource, or are greatly inspired by PalmOS.

Android's Activity and Intent design has some of its roots in work at PalmSource, inspired by a desire to have something like PalmOS's sub-launching facility in a modern, protected-memory operating system. In fact the whole concept in Android of separating applications into distinct components, using Intents to launch the desired part, can very much be seen as a formalization of PalmOS's sublaunching facility and the kinds of things it was growing to do.

The way Android approaches multitasking is very much inspired by PalmOS, with the focus on there being a primary foreground application, which saves its state when you leave it so that when you later return it feels something like it had remained running. In Android we adopted this model, formalizing it more with clearer support for the "save and restore state" model. On top of that, we added the facility to keep these applications running in the background, which has its basis in thoughts back in PalmSource for how to introduce multitasking into such a user model.

(Fwiw, when people talk about webOS's multitasking being superior to Android, my impression is that this is because webOS explicitly keeps applications you launch running and under the user's control for when to stop them. This is actually much more like the traditional desktop multitasking model, which I would argue is less appropriate for mobile devices. The approach taken by Android is a very explicit decision, to avoid serious negatives to a more explicitly multitasking design -- which requires the user to manage what applications are running, and is an especially serious problem on mobile devices where there is no swap so hitting RAM limits due to running too many apps causes serious issues with the overall system's behavior.)

Android was also greatly inspired in PalmOS in its support for different screens, especially screen densities. It was clear to us from experience with PalmOS that different screen densities is important, and it is important to design for them from the start or else you end up in the bad situation PalmOS had when it came to need to do anything besides even multiple scaling. Experiencing these troubles with screen densities and the seriously limitations imposed on the platform by applications defining UIs through absolute layouts lead fairly directly to Android's approach of using density-independent pixels and layout managers. (Ironically, iOS has ended up with the same issue PalmOS had, where there was no original thought for screen densities in the platform, so doing an even multiple scaling such as 2x goes okay, but there is no flexibility to support any other densities without serious compromises.)

And there are many other examples: Android's notification manager and UI was designed with the help of a lot of experience of the utility and limitations of notifications in PalmOS, there is Android's alarm manager which is basically the same functionality as the corresponding API in PalmOS, etc.

Reply Score: 2

chandler Member since:
2006-08-29

The way Android approaches multitasking is very much inspired by PalmOS, with the focus on there being a primary foreground application, which saves its state when you leave it so that when you later return it feels something like it had remained running. In Android we adopted this model, formalizing it more with clearer support for the "save and restore state" model. On top of that, we added the facility to keep these applications running in the background, which has its basis in thoughts back in PalmSource for how to introduce multitasking into such a user model.

(Fwiw, when people talk about webOS's multitasking being superior to Android, my impression is that this is because webOS explicitly keeps applications you launch running and under the user's control for when to stop them. This is actually much more like the traditional desktop multitasking model, which I would argue is less appropriate for mobile devices. The approach taken by Android is a very explicit decision, to avoid serious negatives to a more explicitly multitasking design -- which requires the user to manage what applications are running, and is an especially serious problem on mobile devices where there is no swap so hitting RAM limits due to running too many apps causes serious issues with the overall system's behavior.)


I don't think that's an accurate read on why people like webOS's multitasking. To me it has nothing to do with implementation method and everything to do with user interface. What I like about the webOS style is that it provides a visual sense of state and place associated with managing different tasks and windows. I'm able to organize and arrange what it is I'm doing with my device across multiple applications, and when switching tasks or contexts, I can easily get back to where I left off with just a swipe in the gesture area. This is furthered with the introduction of stacks in later versions, as I can collect a stack of things related to one activity, then quickly switch to some other task or thing I'm thinking about.

To the extent that webOS actually kept things running in those cards instead of doing an Android-style state restoration model, it introduced opportunities for things to bog down the OS. This is probably why some felt that webOS didn't perform very well. But there's no reason why a state restoration model couldn't be used to optimize card-style multitasking.

webOS cards also scaled to handle inter-app multitasking, which is very poorly handled on Android today. Every app needs to introduce its own form of tabs if it wants to allow users to do more than one thing at a time, and there's no systemwide UI to handle this consistently. On versions of Android that support split-screen multitasking, it's not possible to multitask an app with itself to see more than one web page or email at a time for example.

The other key part of this model is that when you launch an app in webOS, it either takes you to an existing card for the app or opens a new card from some well defined starting point for that app. With the Android and iOS style of multitasking, opening an app in the launcher could take you anywhere, and it often depends on how much RAM your device has. I find this terribly confusing, personally, and would rather have it that opening an app from the launcher always produced a consistent result.

In essence, the webOS model gives users the ability to manage application state as a first class concept, and could easily have been extended to benefit from a state-restoration model. One could even imagine an interface to save cards across phone reboots using this approach! The Android model on the other hand hides the concept of state from the user, and randomly destroy's the user's state whenever the phone feels like it.

Lastly - state restoration in Android is fraught with peril. To correctly implement it, apps must able to serialize their own activity stack, which is basically the same thing as swapping except implemented at the application level (and thus a bundle of poorly tested code tightly coupled to application logic). Even Google's own apps often crash or abruptly send the user back to the starting activity when something like an incoming call causes activities to be destroyed. In my opinion it's not possible for mere mortals to correctly handle the serialization required to implement this on Android, and I'll re-evaluate when apps like the Google Play store start getting it right. Whether implemented at the VM or the OS level, something conceptually equivalent to swapping would work much better in practice. In the meantime, multitasking on Android remains an inconsistent mess.

Reply Parent Score: 3

chandler Member since:
2006-08-29

Can't edit anymore, but I meant to say "intra-app multitasking" where I said "inter-app multitasking".

Reply Parent Score: 1