WebOS

Phone's OS is outta date (first world problem)
Colors won't calibrate (first world problem)

—MC Frontalot

I never got around to writing about the first Palm webOS app I wrote for my Palm Pre Plus, but I did, and it was kind of neat. It's a wallpaper switcher that works with photos you sync over to it, and I was able to (eventually) get it completely working, at least on my phone. It's a little janky in that the swapping is hardcoded to every six hours, and it's a pain to add wallpaper, but since webOS doesn't offer any filesystem operations to "real" webOS apps, that'll have to do. (You have to "Add wallpaper" and pick the next one individually for every wallpaper you want to cycle through; really annoying for the 60 or so I wanted on there.)

Since then I started making the first Make A Face mobile app, which has been even more annoying. My current strategy has been to use just a plain WebView widget that loads the site, and use its addUrlRedirect() method to intercept requests to a special URL to trigger special app behavior. (The web site can't tell if it's an app, of course, so this URL will be a "use one of these fine apps!" navitorial page when you use a plain mobile browser.) Seems like this strategy is supported on Android, too, so hopefully an iPhone app could do something similar as well.

While I eventually figured out how to get the camera to trigger and work, that only brought me one rung up the problem ladder. Since this is an app for a mobile device, I don't suppose it would be kind to try to upload a whole megabyte of full-resolution JPEG over a cellular link. (Even when I try to do that in dev, on a snappy wifi network, a few hours I'm not getting back discovered Django ends up taking way too long to un-MIME the multipart/form-data request, making the load balancer time out before it's done.)

In a real program, of course, I would need only resize the image before uploading. Even a modern contender for leading mobile OS should have something to let me do this (especially since so many other apps using the camera surely need similar support). WebOS, however, does not; while I could create a dummy WebView to display the image so I can saveViewToFile() a smaller version to disk, that method only produces PNG images. Such an image would still clock in at 400 KB (according to this tiny manual test I just did), so that probably still won't work.

The doubly disappointing part about being restricted to "web" technologies in webOS is how superficial its webbiness is. In reality it's an application runtime plopped ramshackly atop Webkit. If you say "you write applications in HTML and javascript!" then you would expect to, say, add a button in your application like so:

<button id="do-thing">Do a thing</button>

<script type="text/javascript">
$('#do-thing').click(function () {
    doAThing();
});
</script>

but a webOS application is really more like:

sources.json

[
    {
        "scenes": "main",
        "source": "app/assistants/main-assistant.js"
    }
]

app/views/main/main-scene.html

<div x-mojo-element="Button" id="do-thing"></div>

app/assistants/main-assistant.js

function MainAssistant() {}

MainAssistant.prototype.setup = function() {
    this.controller.setupWidget('do-thing',
        this.dothingAttr = {
            label: 'Do a thing',
        },
        this.dothingModel = {});
    Mojo.Event.listen(this.controller.get('do-thing'),
        Mojo.Event.tap, this.handleDoAThing.bind(this));
};

MainAssistant.prototype.handleDoAThing = function(event) {
    doAThing();
};

There are several layers of misunderstanding muffling the simple idea that "the web page is the app." It gets old fast.

Newer versions of webOS do offer a way to break out of that marketecture straitjacket, which is that you can write "plug-ins" in compiled code that run as standalone applications (a regular "PDK" app) or inside a managed "web" application (they call these "hybrid" apps). Only the former is well supported, because it was an emergency effort to let people port games to the devices.

Unfortunately I hadn't noticed a couple gotchas that exist for plugins. One is that the SDK tools will only build either standalone PDK apps that run on the desktop from Xcode or ARM plugin binaries that run on the device, not x86 plugin binaries that run in the SDK's Virtualbox emulator. The other is that the hybrid plugin apps are only supported in webOS 1.4.5, which I mistakenly assumed was the latest existing release—but it's not, that's 1.4.1.1. Since I have a real device with Verizon service, I'm not allowed to update the OS until Verizon makes it available.

That is, the gotchas for hybrid apps are:

• You can't yet use them in the emulator.
• You can't yet use them on the device.

I guess I can leave the paved path and try to compile an x86 plugin binary for the emulator, but that plugins don't work in the emulator is documented in the FAQ. In fact, that answer seems to cover regular PDK apps too, so there's no reason to think the emulator OS supports running non-"web" apps at all (other than that it's just a Virtualbox image, so it's strange that they would prevent binaries from running like that).

Even if I could run a hybrid app, there's still a last leg of the journey to take, which is figuring out how to actually modify and recompress a JPEG in C code. WebOS is a runtime on top of Linux, so PDK apps use SDL for everything. That might make it easy: they do provide SDL_image, so as long as they provide the JPEG codec, it should be a pretty simple matter.

To make a long story short, I hope to tell you about writing a cool mobile app, but this isn't it.