February 16, 2009

Developing For Palm webOS: Free Book Chapter

Filed under: Groundwork — mikecane @ 2:20 pm


First Chapter of “Palm® webOS™: Developing Applications in JavaScript Using the Palm Mojo™ Framework” Now Available

There’s no direct link to the post itself, but right now it’s the top post at the Palm Developer Network blog.

What’s most interesting is this confirmation of rumor and revelation:

The core OS is based on a version of the Linux 2.6 kernel with the standard driver architecture managed by udev, with a proprietary boot loader. It supports an ext3 filesystem for the internal (private) file partitions and fat32 for the media file partition, which can be externally mounted via USB for transferring media files to and from the device.

So there are two file partitions? For some reason, that makes me itchy. It brings back visions of classic PalmOS — especially the flavor on my LifeDrive, where, surprise!, there are two file partitions. The apps can reside in any partition, but media (.jpg, .mp3, .avi) can only reside in certain ones.

And the kernel of Linux 2.6? According to the Linux Kernel Archives, is the latest stable release. So, it seems the heart of the Pre is in the modern era.

Then there’s this bit:

The media server is based upon gstreamer and includes support for numerous audio and video codecs, all mainstream image formats, and supports image capture through the built-in camera. Video and audio capture is not supported in the initial webOS products, but is inherently supported by the architecture. Video and audio playback supports both file and stream-based playback.

Bold emphasis added by me.

The author of this book is Palm’s own Vice President and Software Chief Technology Officer, which makes me wonder if the claim that “video and audio capture is not supported in the initial webOS products” is rather slanted and should actually be, “video and audio capture is not supplied by Palm itself in the initial webOS products.” Given that the hardware is capable of both, I see no reason why a third-party couldn’t supply them, unless doing so would rely on low-level APIs Palm isn’t (yet) willing to distribute. Let’s remember that the iPhone out-of-the-box can’t do video recording, but that didn’t stop a developer from providing a hack.

Finally, let’s chew on these:

Palm webOS is designed to run on a variety of hardware with different screen sizes, resolutions and orientations, with or without keyboards and works best with a touchpanel though doesn’t require one.

Different resolutions? In what way is that meant? Are all stable screen elements — such as icons and UI gadgetry — based on dynamically-rescalable outline graphics and not bitmaps?

And this:

Because the user interface and application model are built around a web browser, the range of suitable hardware platforms is quite wide, requiring only a CPU, some memory, a wireless data connection, a display, and a means for interacting with the UI and entering text.

Bold emphasis added by me.

That’s confusing. It makes it sound as if everything is running in a browser. Is it?

It’s way too early to tell — at least for a non-coder eejit like me — if we’re going to see any confirmation of the architectural speculations David Beers made, quoted in a previous post: The Heart (And Tentacles) Of The Pre?

Even in the first chapter, it’s clear this book isn’t intended to be Palm Pre Development for Dummies. It presupposes some prior knowledge, such as that of both DOM and MVC. I’m sure those already in the know will find it very helpful.



  1. A few points:

    – The two file partitions make sense. The ext3 one is for internal use since it’s an OS-only playground. The FAT32 is there so when you connect the device to USB on a desktop or laptop, it shows up as a regular file system that is supported by just about every OS out there so you can copy files/media back and forth. This way you don’t need any special drivers installed to access the device.

    – That iPhone video app is only for jailbroken apps. It sounds like core webOS supports video/audio capture at the OS-level, but they just aren’t exposing the API to developers yet. That may be a timing thing or a matter of performance tuning. Video capture requires pretty hefty computing power to compress the content, which may interfere with background apps. My guess is they don’t want to push it out until they’ve had a chance to optimize and tune the OS.

    – ‘It makes it sound as if everything is running in a browser. Is it?’

    Yup. It means that we’ve come full-circle to where people kept saying Netscape would take over the OS and do away with desktop-only apps. Of course, it didn’t happen because they wussed out. But essentially what you have is a browser *runtime engine* as the public face of your operating system desktop/launcher service. Imagine each app on the Palm as a desktop browser tab, but each running simultaneously.

    The difference between a desktop app and a browser-based app today is basically whether one is interpreted (Javascript) vs. compiled, and how much of the local system’s services you can access. A desktop app has full access to things like raw networking, database, filesystem, multi-threading and background services, whereas a browser doesn’t. It sounds like what Palm’s done is expose some or all of these types of services to the browser via Javascript. The question is how much will they expose and how can they keep it secure from snooping malware downloaded from the web. It’s not a new idea. MS has supported browser apps in IE for a long time. Konqueror (now Yahoo widgets) is based on similar technology and Apple took baby-steps toward this with Dashcode, but didn’t go all the way. These guys look to be pushing it the farthest.

    The chapter is just a teaser. They’re dribbling it out to build interest (and obviously, it’s working ;-) But it raises a lot of technical questions that remain to be answered.

    Comment by ramin — February 16, 2009 @ 2:45 pm | Reply

  2. File partitions:
    It’s not very surprising that there are multiple partitions (and note it says “ext3 filesystem for the internal (private) file partitions” <– potentially multiple ext3 file partitions. Linux typically will have multiple file partitions (eg, a root partition, a /boot partition, a swap partition, etc). ext3 has many advantages over Fat32 and therefore makes sense to use in the main OS, but Fat32 makes a lot of sense for the media partition since that what is industry-wide supported.

    Different resolutions:
    From many screenshots I’ve seen, the main screen looks like it automatically and dynamically resizes as notifications come in. Example: Figure 8 in the Chapter 1 of the WebOS overview shows even the card view being shrunk down due to 3 dashboards at the bottom. And then each of the cards themselves are dynamically sized for this new screensize. So it seems the different resolutions will come very easy to the WebOS.

    Another noteworthy mention is the “with or without keyboards” – that would have to mean there is a soft keyboard available. I have not seen that mentioned anywhere, but very much wondered if there would be one. Seems like a soft keyboard could come in very handy at times (such as when holding the device in landscape mode).

    Everything running in a browser:
    It makes sense with the Mojo toolkit that everything runs on some sort of a browser framework. Or maybe a better analogy is that everything is running from a sort of web application server running on the device.

    Comment by Jeff — February 16, 2009 @ 2:57 pm | Reply

  3. @raimn & jeff: Thanks for the partition expertise. That makes sense now.

    If browser-centric cellphones are to be the future, what will Google do vis-a-vis Android and Chrome? Why any need for Android if Chrome could be the basis of it all?

    Comment by mikecane — February 16, 2009 @ 3:32 pm | Reply

  4. Chrome could be turned into an app interface, but they’ll have to add a bunch of plugins to expose OS services to Javascript. Then you have to package the whole thing so an app that consists of multiple HTML, CSS, JS, and image files can be put into a single downloadable bundle, then sign the whole thing so developers can be identified and paid for it. Instead, Android chose to go the route of the Java app. So instead of the browser becoming the engine through which apps run, the embedded Java VM becomes one.

    The Java API is much richer than the vanilla Javascript API. My guess is Mojo is all about adding support for Java-type APIs into Javascript.

    The WebOS approach isn’t panacea either. Be curious if they create a ‘compiler’ that converts JS into binary code (app developers may get nervous if they have to ship their app source code with each copy). Java compiles into bytecode as does Objective-C. It’s easy to decompile, but it offers a bit of assurance to developers.

    Also, there’s the question of an honest-to-goodness resolution-independent UI. If you’re planning on supporting multiple devices, then an app built for 320×480 may not scale well up to 600×800. If you use lots of JPG and PNG files in your interface, it’ll look like crap when it’s blithely scaled up. If you require high-rez artwork, then your apps become bloated. So maybe you do vector graphics, but that can be slow. It’s a big problem and if they don’t solve it upfront, it can mean lots of pain down the line.

    And let’s not even start with access to OpenGL for 3D gaming.

    So yeah, they make a a lot of claims. We’ll see how it turns out.

    Comment by ramin — February 16, 2009 @ 3:55 pm | Reply

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at

%d bloggers like this: