Recently K had a software update on her Palm Pre, following this we decided to checkout the state of the app store. The conversation was brief:
“Is there a tube map yet?”
“Nope, I’m afraid not. Still nothing.”
“Can’t you write me one? You like programming ….”
“Well, yes. I do. I can …”
Thus I set about poking around on the WebOS developer site, installing the SDK and following the Hello World tutorial. I’ve got to hand it to Palm, this is a *really* nice developer experience.
They have a decent emulator (by wrapping VirtualBox in a little launcher UI, palm-emulator), a rails like project generator (palm-generate), a simple packager and installer for getting things onto the (emulated) device (palm-package and palm-install) and there are a bunch more programs they provide which I assume are equally useful. I’ve yet to try out their IDE support yet, as I’m not an IDE person and just wanted to get stuck in and I already have js2-mode enabled in my editor of choice.
Once I’d finished fudging through Hello World I palm-generated a new project and hacked together the start of a tube app.
After several iterations I realised that the easiest way to have a pannable map was just to load the map into an <img> and have that inside a Mojo Scroller widget. This after an evening trying to make ImageView do things it can’t… I quickly loaded this 3 lines of HTML “app” onto K’s phone to prevent her having to carry a paper tube map, now I can take my time playing around with the WebOS API’s and hacking together a more full featured tube application for the WebOS.
> After several iterations I realised
> that the easiest way to have a
> pannable map was just to load the
> map into an and have that
> inside a Mojo Scroller widget.
What, no overengineering when given the chance? Are you getting lazy? 🙂
On the subject of public transport data/apps: I’ve been thinking of doing an app on top of the local route planner API here (http://www.reittiopas.fi), but unfortunately their definition of open interfaces is the usual: “Development and testing free of charge, anything else negotiated separately”. :/
I could just say “well, it’s their loss” but the reality of course is that it’s my loss and the loss of every other tax payer here…
Fret not, there’s plenty of opportunity left for over-engineering in the extra features!
Your situation sounds similar to what the TFL offer us here, they have public “sample” API’s (i.e. useless) and for anything else get in touch. Fortunately some enterprising person provides an API and feeds of all the data I need by scraping the TFL site and publishing it under a CC license (http://tubeupdates.com/). Saves me a job. 😉
We have rumblings here about making the output of tax payers money free for the tax payers, software developed for the government should be open source, API’s should be free to use, etc, etc. Of course it’s all just empty promises until it happens.
I’d like to think if you tried to negotiate they would be receptive to an open source developer? Though if nothing else it’s an extra wall to climb over :-/
Comments are closed.