Linked by Thom Holwerda on Mon 11th Mar 2013 14:51 UTC
PDAs, Cellphones, Wireless After a few months of planning, several weeks of work, and possibly a few kilometres of aimless pacing through the living room, I'm happy to present "Palm: I'm ready to wallow now". This massive article (22,000 words) covers countless aspects of Palm, its devices, its operating system, and the company's importance to the mobile industry. I start with a detailed look at the history of handwriting recognition, after which I move on to the four hardware products I believe are crucial in understanding Palm as a company. Of course, I also dive into Palm OS, covering the kernel, its filesystem (or lack thereof), 'multitasking' capabilities, user experience, and much more. Important Palm OS licensees like Sony and Handspring make an appearance, and I cover the failed attempt at modernising the Palm OS: Palm OS 6 Cobalt. Finally, the conclusion ties it all together. For the first time in OSNews' history, you can also buy this article to support OSNews and make more articles like this possible in the future (don't worry - the regular online version is free, as always!). I suggest you grab a coffee, sit back, and enjoy.
Thread beginning with comment 555473
To view parent comment, click here.
To read all comments associated with this story, please click here.
le_c
Member since:
2013-01-02

what does a "distributed view hierarchy" means? does it means that some views can run in different processes?

Can critical components (e.g. flash) run in a different process and render into a local view? Or was it that way that view and component are one unit running in a different process? thanks for the nice insight btw!

Reply Parent Score: 1

hackbod Member since:
2006-02-15

Yep, it allowed you to have process boundaries at any points in the hierarchy, and one of the significant motivations was indeed for dealing with things like flash content. Basically the entire UI was one single distributed view hierarchy, rooted at the display, with the window manager sitting at the top owning the display and the top-level children there. If you know about OpenBinder, a short description is that in the design every View was an IBinder object, so it had binder interfaces for accessing the view allowing these to go across processes. In particular there were three interfaces:

- IView: the main interface for a child in the view hierarchy.
- IViewParent: the interface for a view that will be the parent of other views.
- IViewManager: the interface for managing children of a view.

These interfaces also allowed for strong security between the different aspects of a view. For example, a child view would only get an IViewParent for its parent, giving it only a very limited set of APIs on it, only those needed to interact with it as a child.

You can look at the documentation on the binder storage model at http://www.angryredplanet.com/~hackbod/openbinder/docs/html/index.h... to get a real-life flavor for a similar way to deal with objects that have multiple distinct interfaces with security constraints between them. In fact... the view hierarchy was *also* part of the storage namespace, so if you had the capability to get to it you could traverse down through it and examine it, such as from the shell!

Many of the fundamentals of this design were carried over to Android. Android dropped the distributed nature of the view hierarchy (switching to Dalvik as our core programming abstraction with Binder relegated to only on dealing with IPC lead to some different design trade-offs), but still we have our version of IViewParent in http://developer.android.com/reference/android/view/ViewParent.html and the basic model for how operations flow down and up the hierarchy came from solving how to implement that behavior in the Cobalt distributed view hierarchy.

Reply Parent Score: 1

le_c Member since:
2013-01-02

Find that pretty interesting stuff!

I don't quite understand why switching to Dalvik made you drop the distributed nature of the view hierarchy though.

Looked into OpenBinder before. As one part of my PhD project I look into how the behaviour of an application can be changed at runtime (basically by rewiring components). For the prototype I used many ideas from OpenBinder and especially pidgen to generate the base object binder code. However, I mixed in a bit of qt's thread safe signal/ slot semantic to make it easier to make stuff thread safe (http://qt-project.org/doc/qt-4.8/threads-qobject.html).

Is there actually something you miss from the Cobalt platform (binder related) that is not in Android?

Reply Parent Score: 1