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 555507
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:

Part of this is that a lot of those features in OpenBinder were based on creating a dynamic nature as part of the core binder design. When we went back and started on a new platform based on Dalvik, we already had a language with its own dynamic nature. Just taking what had been done for OpenBinder would leave us with these two conflicting dynamic environments. We even ended up dropping the basic ability to have multiple binder interfaces on an object because that didn't map well to the Java language. (In theory you can still implement such a thing on Android based on the native binder framework, but not in Dalvik where most of the interesting stuff happens.)

There was also just a practical issue that we couldn't take the OpenBinder code as-is for licensing reasons, so we needed to re-write it for what we shipped in Android. The development schedule for Android was pretty tight, so we needed to be really efficient in building the system, and reproducing all of OpenBinder and the sophisticated frameworks on top of it that weren't open-sourced would have been a lot of work that was hard to justify vs. what we would get by going back and doing something slightly different that leveraged a lot more of Dalvik.

And ultimately it was a different team that built Android -- yes some key people were from PalmSource with the experience with Cobalt, but there was a lot of influence as well from people coming from Danger, Microsoft, and other places. Ultimately ideas from all those places were mixed together by picking and choosing those that seemed best for the project.

I also think that from a development perspective building most of our system services on top of Dalvik has been a good thing for Android. The Dalvik environment is just a much more efficient development environment than C++; with all of our very core system services like the window manager and package manager written in it, we can move much more quickly in evolving our platform and more easily triage and fix bugs. (Given a crash report from someone's device, you are very often going to be able to identify and fix the problem when it happens in Dalvik far more quickly issues than in native code.)

Reply Parent Score: 1