Posts Tagged ‘webOS’

What webOS did better…

Having recently upgraded from a Palm Pixi to a iPhone 4S, leaving behind webOS for iOS, it’s easy to find many things that are vastly superior on iOS; not surprising, given the superior hardware on the iPhone and the relative maturity of iOS as a platform. However, I find myself missing a few things I’ve become accustomed to with webOS; things I think webOS simply did a better job at.

While both platform alert you to events, webOS also kept notifications stacked on the bottom of the display until you chose to swipe them away.


Integrated Contacts
webOS automatically imported and linked contacts from multiple sources (Facebook, Gmail, etc.) making it fairly simple to manage (or more accurately, not have to manage) an address book.

integrated contacts

While iOS supports multitasking on a technical level, on a UI/UX level the focus is very much centered on one app at a time, as swapping between apps always requires a trip back to the home screen. The webOS process of sliding between cards was not only a slightly faster method to swap between apps but also fairly convenient when it came to glancing at something in another app and then getting back to what you were doing; the scenario that pops into my mind is texting something from a webpage but not remembering it exactly or entirely, and having to swap between the messaging app and the browser.

Also, swiping a card up and off the screen was a fairly elegant way to close it. Exiting apps is perhaps not a big of a deal on an iPhone due to the larger memory pool, but when you do near the memory limit, I’m not sure double tapping the home button, pressing and holding the app icon, and hitting the remove icon is the easiest nor most intuitive action.


Map directions request on webOS

Very simple, but not well documented.

First, here’s a typical call to launch the maps app and display a position (latitude, longitude + title) on the map:

this.controller.serviceRequest("palm://com.palm.applicationManager", {
parameters: {
params: {
query: escape(latlong) +
"(" + encodeURIComponent(title) + ")"

To launch the maps app and bring up the directions panel instead, replace query with daddr:

this.controller.serviceRequest("palm://com.palm.applicationManager", {
parameters: {
params: {
daddr: escape(latlong) +
"(" + encodeURIComponent(title) + ")"

google directions on webOS

Packaging for webOS 1.4.5

The newer SDKs don’t compile an IPK for webOS 1.4.5, but you can use the awesome Ipk Packager by Jason Robitaille to make a 1.4.5 package.

Ipk Packager 1.5

webOS list modelChanged bug

I ran into a bug with the webOS mojo framework a while ago, which I nailed down thanks to this forum post. Simply put, calling this.controller.modelChanged on a list doesn’t work properly if the user has scrolled down the list. With the dotspott webOS app I notice a gray rectangle popping up, obscuring the last 2 items in the list.

From pacemkr,

Calling this.controller.modelChanged on a list that has been scrolled past renderLimit will blank out the screen and not show the changes. This happens because modelChanged handler in the List widget resets renderOffset to 0. In other words the list widget assumes that the user is at the top of the list when modelChanged event happens. This is a pretty nasty bug.

The solution is to use mojo.setLengthAndInvalidate() instead:


While Mojo has been superseded by Enyo, this is still a pretty big deal, there’s still lots of Pixi and Pre models out there with webOS 1.4.5.

webOS file upload

This is something pretty basic, but the example in the API documentation leaves a lot to be desired and, if I recall correctly, doesn’t even work.

So here’s how to do a file upload on webOS, sending the file along with additional data in the POST call.

One critically important point to take note of is that session information is not passed from your app to the com.palm.downloadmanager service so, if necessary, you must verify and authenticate the user again. As I was using PHP for my server-side stuff, I looked into getting and passing the PHPSESSID cookie, but I couldn’t figure out how the get the value, webOS does not seem to store it with other cookies.

// additional POST data
// spot_id, userName, password declared elsewhere
var post_params = [
'key': 'id', 'data': spot_id, 'contentType': 'text/plain' },
'key': 'username', 'data': userName, 'contentType': 'text/plain' },
'key': 'password', 'data': password, 'contentType': 'text/plain' }

'palm://com.palm.downloadmanager/', {

// myfile = fileName of file to upload
// url_to_web_service = URL to server-side script that will handle file upload
// Note, contentType is mime type of file (according to docs), but 'img' used for images?!
parameters: {
'fileName': myfile,
'fileLabel': 'my_cool_file',
'url': url_to_web_service,
'contentType': 'img',
'subscribe': true,
'postParameters': post_params

function (resp)
if (resp.responseString) {
// file has been uploaded             
else {
// file partially uploaded, resp contains progress info

function (e)
// something bad happened!

On the server-side, the file is identified by the value of ‘fileLabel’ (in this case ‘my_cool_file’), and the additional POST data is identified by the value of the key field.


Using the ImageView widget is somewhat perplexing. The documentation states:

This widget is designed to view an image full screen with support for zooming and panning…

You would assume that you could simply create the ImageView widget and it would be full screen and handle orientation changes (something very essential and common when viewing photos) out of the box. Unfortunately, this is not the case and some additional code is necessary to get it to function as such.

dotspott photo view

I’ll present some code here, but much of what I did was based on the code at webOS 101.

First, a few additions to the assistant’s activate function:

  • We setup full-screen mode
  • Set “free” orientation (allows the system to rotate the display)
  • Manually size the ImageView widget (id=photoView)
ViewPhotoAssistant.prototype.activate = function(event) {

'photoView').mojo.manualSize(Mojo.Environment.DeviceInfo.screenWidth, Mojo.Environment.DeviceInfo.screenHeight);

/* set images here */

To actually respond to orientation changes we need to setup an event listener for the “resize” event. This is dealt with in the assistant’s setup function:

ViewPhotoAssistant.prototype.setup = function() {
var photoViewerAttributes = { noExtractFS: true };
var photoViewerModel = {};

this.controller.setupWidget('photoView', photoViewerAttributes, photoViewerModel);
// setup handler for resize event ...
this.handleWindowResizeHandler = this.handleWindowResize.bindAsEventListener(this);
this.controller.listen(this.controller.window, 'resize', this.handleWindowResizeHandler);

/* other setup code... */


Within the resize event handler, we manually resize the ImageView widget based on the new dimensions of the window:

ViewPhotoAssistant.prototype.handleWindowResize = function (event){
if ($('photoView') && $('photoView').mojo) {
'photoView').mojo.manualSize(this.controller.window.innerWidth, this.controller.window.innerHeight);

Finally, in the assistant’s cleanup function, we stop listening on the event:

ViewPhotoAssistant.prototype.cleanup = function(event) {

this.controller.stopListening(this.controller.window, 'resize', this.handleWindowResizeHandler);    



I missed webOS Developer Day, but I took a look at the presentation of the Enyo framework (video below). I like most of the bullet points: faster performance, hardware acceleration built-in, etc. However, one point that’s troubling me is the idea of using higher-level controls instead of divs. From the bit of code presented in the final demo, it looks like layout (and pretty much all UI stuff) will be done using JavaScript widgets, which are translated at some point into the appropriate HTML constructs. Obviously, widget-centered development isn’t a new concept (MFC, WinForms, Cocoa… sproutcore and such on the web) nor is it necessarily a bad one (getting something presentable up and running is easier), but there always seems to be a very real and very large loss of flexibility.

When a widget doesn’t look or function exactly how you need it to, and it becomes necessary to make a new one, development within the widget framework can range in difficulty from trivial to near-impossible. As I mentioned when I wrote about Adobe Air, HTML/CSS isn’t perfect, but it’s the most flexible layout and styling framework I’ve come across. Abstracting away that flexibility in favor of plug-and-play widgets makes me cringe… it’s a nice idea, it’s a very (object-oriented) developer-ish idea, but it usually comes with a pretty high cost.

From working with both HTML/CSS and WinForms extensively, I’d say the widget-centered framework model used for desktop apps shouldn’t be replicated for web development. In fact, it should be the other way around: the flexibility of a HTML/CSS-esque system should be brought to the desktop.

How this will play out for Enyo, I don’t know. I’m cautiously optimistic. Being a web framework, everything still boils down to HTML and CSS, but it remains to be seen what level of manipulation will be allowed or make sense (in terms of performance, coding difficultly, etc.) at that level.

dotspott 1.3.x for webOS

dotspott for webOS v1.3.0 should now be available in the webOS app catalog.

dotspott webOS screenshot 1 dotspott webOS screenshot 2 dotspott webOS screenshot 3

Primarily, there’s a new look compared to the older hotspotdot app. Not a whole lot of new features, but two noteworthy additions:

  • dotspott will show your current locations and, using the Google Map API, reverse geocode the latitude, longitude pair to tell you where you are.
  • Support for attaching photos to spotts

A smaller update (v1.3.1) should out in the coming week with some minor stylistic additions.

webOS command menu icons

The list of standard icons for the command menu buttons aren’t found anywhere in the developer documentation.

webOS command menu

h/t to Jason Robitaille for his post on the forums with the list of icons pulled from /usr/palm/frameworks/mojo/submissions/175.7/stylesheets/global-menus.css

/* Example Icons */

.palm-menu-icon.back { background-image: url(../images/menu-icon-back.png); }
.palm-menu-icon.forward { background-image: url(../images/menu-icon-forward.png); }
.palm-menu-icon.refresh { background-image: url(../images/menu-icon-refresh.png); } { background-image: url(../images/menu-icon-search.png); } { background-image: url(../images/menu-icon-new.png); }
.palm-menu-icon.stop { background-image: url(../images/menu-icon-stop.png); }
.palm-menu-icon.attach { background-image: url(../images/menu-icon-attach.png); }
.palm-menu-icon.compose { background-image: url(../images/menu-icon-compose.png); }
.palm-menu-icon.conversation { background-image: url(../images/menu-icon-conversation.png); }
.palm-menu-icon.delete { background-image: url(../images/menu-icon-delete.png); }
.palm-menu-icon.file { background-image: url(../images/menu-icon-file.png); }
.palm-menu-icon.forward-email { background-image: url(../images/menu-icon-forward-email.png); } { background-image: url(../images/menu-icon-info.png); }
.palm-menu-icon.priority { background-image: url(../images/menu-icon-priority.png); }
.palm-menu-icon.reply-all { background-image: url(../images/menu-icon-reply-all.png); }
.palm-menu-icon.reply { background-image: url(../images/menu-icon-reply.png); } { background-image: url(../images/menu-icon-save.png); }
.palm-menu-icon.send { background-image: url(../images/menu-icon-send.png); }
.palm-menu-icon.sync { background-image: url(../images/menu-icon-sync.png); }
.palm-menu-icon.edit-profile { background-image: url(../images/menu-icon-edit-profile.png); }
.palm-menu-icon.make-vip { background-image: url(../images/menu-icon-make-vip.png); } { background-image: url(../images/menu-icon-new-contact.png); }
.palm-menu-icon.remove-vip { background-image: url(../images/menu-icon-remove-vip.png); }
.palm-menu-icon.down { background-image: url(../images/menu-icon-down.png); }

Use the name after “.palm-menu-icon.” when setting up the command menu model.

this.cmdMenuModel = {
visible: true,
items: [
{items:[{label: $L('Add'), icon:'new', command:'
{items:[{label: $L('Refresh'), icon:'refresh', command:'

hotspotdot for webOS v1.1.0

The 1.1.0 update for the hotspotdot webOS app is up. You can now create a new account from within the app, share hotspots via. email, update the locations of your existing hotspots, and refresh the current list of hotspots.

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

I can’t respond to reviews in the app catalog, so I’ll do it here.

Potential = 5 stars. Currently, still a work in progress – but fills a much needed void on webOS = being able to save fav places in google maps.

2 features missing:

1. Search via keyword/category. You can enter keywords for your places, but then it just shows everything in a list anyways. Maybe make it autosearch – when the program is open you can just starts typing and the matching entries will pop up.

2. Ability to enter places you aren’t current at. Right now to add any place you have to physically be there. This prevents the most common use of fav places = hear about a good restaurant from a friend and save its location so you can go there later.

Hope to see this developed more…and i’d pay for it!

I’ll definitely work on autosearch. Adding locations that your not currently at is problematic because there doesn’t seem to be a mechanism on webOS by which you can poll the locations of a selected marker from the Maps app. You can, of course, do this from the web app.

2 stars because it functions & is a cool idea….BUT…this is clearly not formatted for WebOS (Or maybe mobile?). I say that because you have to sign up 1st & when the sign in screen loads it is so small as to be unreadable. Once you expand the screen to enter you info, you have to slide aound to get it all in and “submit”.

That might sound harsh/anal but it is the simple things – like useability – that frustrate users and make them look elsewhere.

From Chris T

Very true, the sign-up process was not part of the app prior to this version and the process via. the website really was not designed for a mobile device – though everything should work. This version should make the process more mobile-friendly.

Ok.. Not really what I expected.. I was reading into this as WiFi hotspot designator.. Just a basic location designator?? Uh..ok…

From Anonymous

I was hoping it would perhaps look for “HotSpots”, posibly reporting strength, then recording GPS location, like a sniffer.

From Mark R

There seems to be some confusion that the app deals with wifi hotspots. To (hopefully) avoid this, I’ve altered the app description to the following:

hotspotdot allows you to easily record and tag locations (“hotspots”) that are important to you. Your personal database of locations (and related metadata) can then be accessed to show you exactly where your hotspots are and how to get to them.

Finally, for bug reports, feature requests, etc. you can now email me at