So I'm just about finished my first webOS application, and reflecting back on the past couple days, I noticed that:
- I am not creative, and although I insist on making a "million dollar" app, I don't have the imagination to think it up
- I really appreciate having access to the webOS code via the webOS Doctor jar, as it proved extremely helpful when looking for examples
- The API on developer.palm.com is very disappointing (lack of information)
- The framework is seriously tied down by silly restrictions
To go into #4 in more detail, I'll have to explain my application. One of the foremost complaints of the Pre so far has been the dismal battery life. I won't try to sugar coat that fact, it's pretty bad. So I thought it would be a great application to write an application that tracked and calculated battery performance. This would be useful to track metrics on application configurations, or complete operating system version and see qualitatively if there are changes in battery life.
This should be easy, I thought. Especially with the help of this excellent crash course on webOS development. So being a full-time programmer, I decided to go to the programmer's main resource - the API documentation. This is where my first problem was. Although the API does a nice job of showing the possible web-controls (widgets) you can use, it doesn't give any really nitty-gritty information (i.e. how to get battery levels).
So after being immediately defeated, I decided to try and crack open the my VirtualBox emulator image to read the code that accomplishes this in the status bar. Failing to do that, I found success by extracting the webOSDoctor and searching for bar-assistant.js. This had all the code I needed! Great find, I thought. However there was one more problem...
I copied the code I saw in bar-assistant.js to get the battery info as close as I could without taking in the excess fat. When I launched, I expected it to fail, as programs usually do on their first run, but the error I was getting was claiming that the method I was calling didn't exist. Strange, I thought, I'm pretty sure I copied it correctly. Nevertheless, I tried again... and again... and again. Still, every time the functions did not exist.
By this point, I was pretty frustrated. I had spent hours writing and rewriting the same code trying to look for the smallest of typos. Then I read somewhere that palm locked out part of their functions based on vendor of the software. Bingo! So I changed my app.json information to be a com.palm and vendor=palm and... well whad'ya know - it works!
For those of you who don't find the irony in this yet, there was a little bit of a scuffle between apple and palm about syncing to itunes. The jist of it was that apple didn't want the pre to sync to their software, so they locked out any product without an apple vendor id from itunes. Palm's solution to this? Spoof Apple's vendor id! After doing this, palm took the initiative to complain to the USB forum about locking out devices based on vendor IDs in compliance with open standards... or something like that. However, to get the functionality I wanted, I had to spoof my application as a palm app!
It's funny how things work out.
Anyway, I'm currently waiting for developer access to post my app on precentral.net so keep an eye out and start managing your battery life better!