Posts Tagged ‘webOS’

Attaching a title to a position on Google Maps

One of the neat little things I discovered when doing the hotspotdot webOS app is how to show the custom, user-entered title of the location, as shown below.

Google map location on webOS

This is done by specifying the title in the query, in parentheses, after the coordinates. The full, escaped query URL for the location above is as follows:

http://maps.google.com/maps?q=40.7044120969184,-73.99009709643556%28Empire%20Fulton%20Ferry%20State%20Park%29

The Javascript code for the webOS app would look something like this (latlong and title are variables that hold the latitude, longitude coordinate pair and title, respectively):

this.controller.serviceRequest("palm://com.palm.applicationManager", { method: "open", parameters: { id: "com.palm.app.maps", params: { query: escape(latlong) + "%28" + escape(title) + "%29" } } });

This works in the browser as well, so the URL shown above would display the following,

custom title on Google maps position

hotspotdot for webOS

I originally conceived hotspotdot as a smartphone app, as its utility meshes perfectly with a smartphone’s GPS receiver, but the contest I was entering (Microsoft’s My App is Better Challenge) required a web app. The web app is useful but when it comes to adding a hot spot it’s hard to beat hitting a button and pulling in your global position instantly.

Anyways, the bottom line is I went ahead and built the mobile app anyway. I have a Palm Pixi, so I built it for webOS.

The app was approved and published in the app catalog a few hours ago, so anyone with a Palm Pre or a Palm Pixi should be able to get it soon. It’s free. Also, you’ll need an account at my.hotspotdot.net to use it (sorry, I didn’t add support for account creation within the app).

hotspotdot webOS screenshot 1 hotspotdot webOS screenshot 2 hotspotdot webOS screenshot 3

This if my first webOS app and my first mobile app!

The Mojo framework proved to be fairly approachable. Making everything Javascript + HTML-ish markup was a very good call. However, a few bits of criticism:

  • I ran into some annoyances due to nothing more than flaky documentation. I should say 99% of the documentation is very good and thorough, but small bits of missing info, like needing the .mojo prefix for method calls, can drive you up the wall.
  • A intermediate-level tutorial would have been very much appreciated. Palm has the Getting Started tutorial followed by the fairly advanced Client-Server tutorial.
  • At various point in the documentation (e.g. here) there are examples of declaring buttons in a simpler way, entirely within the DOM (no setupWidget call necessary) and no x-mojo-element attribute on the div. This shortcut should probably be avoided; you have to understand that all you can do with these elements is respond to the Mojo.Event.tap event – you can’t change the underlying model, label, etc.
  • To manipulate/update widgets, you need to modify the widget’s underlying model (an array of properties). This was somewhat surprising to me. I would have figured, in keeping with the JS + HTML scheme and how things are done in an AJAX web app, you would modify the DOM of the view to change things.
  • Mojo uses the Prototype framework. Prototype is okay… AJAX calls are simple enough, but XML parsing was a bit more difficult compared to jQuery, which is more powerful for traversing and pulling elements out of an XMLDocument.
  • You have to work in Eclipse for an integrated IDE experience. I would have much preferred a Netbeans plug-in.

Overall, I’m still pretty happy with the Mojo framework and I was able to code, test, and deploy an app fairly quickly (~2 weeks, working on this on and off; probably less than 72 hours total).

Changing the model of activity buttons on webOS

This little issue drove me insane: you can’t change the model on an activity button after it’s been activated.

So, first, a little background. webOS/Mojo has widgets and one type of widget is a button. Setting up a button requires attributes (to set type – default or activity button) and a model (to set the label, disable/enable, and associated CSS class). A type of Mojo.Widget.activityButton turns the button into an activity button, which adds a spinner (preloader) to the button when the Mojo.Widget.Button.activate() method is called. The Mojo framework also allows altering the model of any widget and calling the Mojo.Controller.SceneController.modelChanged() method to commit the updates.

Here’s some code to show how all of this pieces together. This code is correct and functions as expected.

function setupSignInButton() { var btnModel = { buttonClass: "affirmative", label : "Sign in", disabled: false } var btnAttributes = { type: Mojo.Widget.activityButton } ctrlr.setupWidget("signin-button", btnAttributes, btnModel); Mojo.Event.listen(ctrlr.get('signin-button'), Mojo.Event.tap, function() { btnModel.disabled = true; btnModel.label = "Signing in..."; ctrlr.modelChanged(btnModel); ctrlr.get('signin-button').activate(); }); }

Note, ctrlr is a reference to the scene controller (Mojo.Controller.SceneController).

When the button is tapped, the spinner is activated, the button is disabled, and the label for the button is changed to “Signing in…”, as shown below.

webOS activity button, signing in

The problem is, if you move the call to activate { ctrlr.get(‘signin-button’).activate(); } above the call to change the model { ctrlr.modelChanged(btnModel); }, the model change does not occur. So you have an activated button without the model change, as shown below.

webOS activity button

Note, deactivating the button and attempting the model change does not work.

Edit: After playing with the code a bit more, turns out there’s no need to call activate(), the activity button is activated automatically when the button is tapped. Also, the issue I mentioned above seems to all stem from the call to activate(). It seems no code after the activate() call is executed (I attempted to show an alert dialog) and very much looks like an issue where the activate() call is blocking.

Edit 2: Hmmm, turns out nothing was being blocked, but an uncaught exception was being thrown. If you call a method for a widget as I was doing above, something like the following is thrown:

TypeError: Object# has no method 'activate'

To call a method, you need to put ‘.mojo’ before the method name, so:

ctrlr.get('signin-button').mojo.activate();