Palm Developer Network Blog

Now that Palm Pixi is on the verge of shipping, we’ve released both webOS version 1.3.1 and the new version of the Mojo Software Development Kit.

The highlights of the Mojo SDK version 1.3.1 release are the following;

• Enhanced Pixi support in emulator
• API to keep screen from auto-dimming
• Auto-generation of app Help / Support scene
• Numerous framework doc enhancements

Elaborating a bit on the last item, we’ve heard the developer community’s feedback about webOS docs loud and clear. You’ll see the first efforts to expand, clarify, and improve quality of the docs with this release. Notably, we’ve provided new step-by-step installation instructions, with more thorough information about how to get your system ready before you download and install the SDK. Start on our Download page by selecting the version of the SDK you’d like to use.

For more complete information about Mojo SDK Version 1.3.1, see the Release Notes on webOSdev.

Dan Kurtz, the resident web expert at Self Aware Games, joined Palm on-stage at the Sprint Developer Conference to share his team’s lessons learned from having developed two games for webOS, Word Ace and Card Ace.

The team came to webOS thinking that first reports made it an attractive platform for some of their gaming ideas, especially if they matched the games to webOS core capabilities, such as always-on web connectivity, easy text entry from a physical keyboard, and multitasking. That said, they didn’t take the task of developing a webOS game lightly. As Dan said, “A new platform means problems. Developing a new game means problems. So developing a new game on a new platform meant problems squared.”

To help manage the risk inherent in such an undertaking, they prototyped their first game, Word Ace, on iPhone, since they already had experience on the platform and could get to a playable app quickly. When they turned to implementing the same functionality on webOS, they were able to take advantage of their knowledge of JavaScript, focus on learning the new platform, and implement already-robust features without having to solve for multiple unknowns.

Dan summarized their lessons learned in a few brief points. To paraphrase him:

• Happiness is designing for a single, cutting-edge web environment, which is provided by webOS
• To develop great games on webOS, you need extremely detailed knowledge of JavaScript and CSS
• You can make your life much easier if you design your game around the webOS strengths summarized above
• When you need help or to learn more, use resources on the web including Palm’s webOSdev community forums and open source code.

You can read a lot more about Self Aware and its early webOS development experience in the webOSdev profile of Self Aware Lead Designer Seppo Helava in the “Getting Their Mojo Working” series.

Here’s a summary of all our postings — starting with the latest entry — about Palm’s activities at the Sprint Developer Conference, which was held October 26-28 in Santa Clara.

• webOS developers at Sprint Developer Conference: Pivotal Labs: Chris Sepulveda of Pivotal Labs demos two of their apps and talks about making the transition from traditional web development to webOS.
• What’s Happening in webOSland, part 3: Includes a pointer to the Pre101 write-up of the conference.
• Palm Engineer Demos the Wonders of webOS at the Sprint Developer Conference: The lead engineer for Palm’s webOS phone app explains his motivation in writing another webOS app, Clock, and describes the design and coding of it. Also see the code he developed and added to the app on-stage to add functionality to Clock.
• Complete Schedule of Palm Activities at Sprint DevCon: Palm’s schedule of events at the conference.

Until now, we’ve been pretty nontechie here, but what Palm Engineer Matt Hornyak did during his talk at the Sprint Developer Conference today was so cool that we have to get really technical here, at least for today.

Matt is the lead engineer on the webOS phone app. He also wrote Clock, which ships with Pre. In front of the gathered masses at the Sprint conference - somewhere around 500 of them - he went deep inside Clock. Matt explained his motivation in writing it and then described the design and coding of it.

All great stuff, but he saved the best for last. Wanting a way to change the length of the snooze alarm in the Clock app, Matt cooked up the code, added it to the app, and - voila - Clock had snooze control, running on the device I might add. And all this in about five minutes, in front of a live audience.

Here is the code he used for the control, with Matt’s annotations (in boldface) about what each section does. You might want to take a look at Clock and try adding this yourself, although if you’re not really experienced with JavaScript and Mojo yet, you might not want to make this the first thing you try.

If this is over your head, hang in there. We’re collaborating with Matt on an article about Clock that will include more detailed instructions on how to add the snooze feature. Consider this a sneak preview.

More from the Sprint conference later this week. Check back, ok? Out for now.

Listing 1. Adds the new widget, and the borders around it.

Index: app/views/settings/settings-scene.html
===================================================================
— app/views/settings/settings-scene.html    trunk)
+++ app/views/settings/settings-scene.html    (demo)    @@ -33,5 +33,16 @@
</div>
</div>
</div>
+
+    <div class=”palm-group”>
+        <div class=”palm-group-title”>
+            <span x-mojo-loc=”>snooze</span>
+        </div>
+        <div class=”palm-list”>
+             <div class=”palm-row single”>
+                <div id=”snoozeduration” x-mojo-element=”ListSelector”></div>
+            </div>
+        </div>
+    </div>

Listing 2. Changes settings assistant to set up new widget, and respond to events from it.

Index: app/controllers/settings-assistant.js
===================================================================

— app/controllers/settings-assistant.js    trunk)
+++ app/controllers/settings-assistant.js    demo
@@ -1,6 +1,26 @@
/* Copyright 2009 Palm, Inc.  All rights reserved. */

var SettingsAssistant = Class.create({
+    // values for snooze duration listselector
+    snoozeDurationChoices: [
+        {
+            label: $L("5 min."),
+            value: 5
+        },
+        {
+            label: $L("10 min."),
+            value: 10
+        },
+        {
+            label: $L("15 min."),
+            value: 15
+        },
+        {
+            label: $L("8 hrs."),
+            value: 480
+        },
+    ],
+
initialize: function(settings, themes, onThemeChange) {
this.appController = Mojo.Controller.getAppController();

@@ -14,6 +34,7 @@
this.initializeSettings();

this.onKeyPress = this.onKeyPress.bind(this);
+        this.onSnoozeDurationChange = this.onSnoozeDurationChange.bind(this); // event handler for snooze duration list handler

this.easterString = “”;

@@ -22,8 +43,12 @@
// VERY IMPORTANT: UI for ringer switch has OPPOSITE MEANING of variable
// it’s reversed here for display and must be reversed back when saving
initializeSettings: function() {
-        this.settingsModel = { };
-        this.settingsModel.ringerSwitchObeyed = !(this.settings.ringerSwitchObeyedGet());
+        this.settingsModel = {
+            ringerSwitchObeyed: !(this.settings.ringerSwitchObeyedGet()),
+            snoozeDuration: this.settings.snoozeDurationGet() // load setting for snooze duration into scene’s model
+        }
+
+
},

setup: function() {
@@ -50,6 +75,15 @@

this.controller.get(’theme_set’).observe(Mojo.Event.tap, this.onThemeSelect);

+        this.controller.setupWidget(’snoozeduration’, { // setup snooze duration’s listselector widget
+            label: $L(’length’),
+            choices: this.snoozeDurationChoices,
+            modelProperty: ’snoozeDuration’,
+            labelPlacement: Mojo.Widget.labelPlacementLeft
+        }, this.settingsModel);
+
+        this.controller.listen(’snoozeduration’, Mojo.Event.propertyChange, this.onSnoozeDurationChange);
+
this.controller.listen(this.controller.sceneElement, Mojo.Event.keypress, this.onKeyPress);

},
@@ -74,6 +108,10 @@
this.settings.ringerSwitchObeyedSet(!(this.settingsModel.ringerSwitchObeyed));
},

+    onSnoozeDurationChange: function() { // respond to events on list selector widget
+        this.settings.snoozeDurationSet(this.settingsModel.snoozeDuration);
+    },
+
themeUpdate: function() {
var theme = this.themes.getCurrentTheme();
this.controller.get(’theme_name’).textContent = this.themes.getNicename(theme.name);

****end of framework-specific code; the rest is app-specific

Listing 3. Changes settings model to get/save snooze length.
Index: app/models/settings.js
===================================================================
— app/models/settings.js    (trunk)
+++ app/models/settings.js    (demo)
@@ -36,7 +36,8 @@
timePickerInterval: 5,
dashboardHide: false,
ringerSwitchObeyed: false,
-            initialized: true
+            initialized: true,
+            snoozeDuration: 5
};

this.save();
@@ -72,9 +73,18 @@

ringerSwitchObeyedGet: function() {
return this.values.ringerSwitchObeyed;
-    }
+    },

+    snoozeDurationGet: function() {
+        return this.values.snoozeDuration || 5
+    },
+
+    snoozeDurationSet: function(value) {
+        this.values.snoozeDuration = value;
+        this.save();
+    },
+
});

Settings.kCookieKey = “settings”;

Listing 4. Changes alarm model to have adjustable snooze time.
Index: app/models/alarm.js
===================================================================
— app/models/alarm.js    (trunk)
+++ app/models/alarm.js    (demo)
@@ -341,12 +341,19 @@
},

// snooze this alarm.  pass true to indicate that it was snoozed by another popup opening
-    snooze: function(alarmInterrupted) {
+    snooze: function(alarmInterrupted, duration) {
var newParams = Alarm.kAlarmLaunchParams.evalJSON();
newParams.params.id = this.id;
if (alarmInterrupted) {
newParams.params.alarmInterrupted = true;
}
+
+        if (duration) {
+            duration = “00:” + duration + “:00″
+        } else {
+            duration = Alarm.kAlarmSnoozeDuration;
+        }
+
var newParamsJSON = Object.toJSON(newParams);
this.schedulerSetRequest = new Mojo.Service.Request(Alarm.kAlarmSchedulerUri, {
method: “set”,
@@ -355,7 +362,7 @@
“key”: Alarm.kAlarmSchedulerKeySnooze+this.id,
“uri”: Alarm.kAlarmLaunchUri,
“params”: newParamsJSON,
-                ”in”: (alarmInterrupted ? Alarm.kAlarmSnoozeInterruptedDuration : Alarm.kAlarmSnoozeDuration)
+                ”in”: (alarmInterrupted ? Alarm.kAlarmSnoozeInterruptedDuration : duration)
},
onSuccess: function(payload) {
// Mojo.Log.info(”Alarm: snooze succeeded”);

Listing 5. Changes ring notification to get snooze length.

Index: app/controllers/ring-assistant.js
===================================================================
— app/controllers/ring-assistant.js    (trunk)
+++ app/controllers/ring-assistant.js    (demo)
@@ -5,6 +5,7 @@
initialize: function(params){
this.appControl = Mojo.Controller.getAppController();
this.appAssistant = this.appControl.assistant;
+        this.settings = this.appAssistant.settings;

this.alarmOff = this.alarmOff.bindAsEventListener(this);
this.snooze = this.snooze.bindAsEventListener(this);
@@ -55,7 +58,7 @@
} else if (this.shortSnooze) {
this.alarm.snooze(true /* short snooze */);
} else {
-            this.alarm.snooze();
+            this.alarm.snooze(false /* not short snooze */, this.settings.snoozeDurationGet());
}
},

We’ve got a lot going on at the Sprint Developer Conference in Santa Clara next Monday, Tuesday, and Wednesday. You’ll have a lot of chances to hear from some of our experts and members of the webOS development community and to hang out with folks from Palm. Here’s an entire schedule of our participation:

MONDAY

9:30-10:30 AM Getting Started with Palm® webOS Apps, PART 1: The webOS Opportunity and Technical Overview. Ben and Dion with Mitch Allen, Palm Software CTO

Find out why webOS has generated so much excitement in both the web and mobile developer communities, and get a look under the hood at this game-changing OS from one of the engineers who led its development.

10:40-11:40 AM Getting Started with Palm® webOS Apps, PART 2: UI and app design details. Geoff Schuller, Palm UI, and Matthew Hornyak, Palm Engineering

Geoff Schuller will start things off with a review of general webOS app HI Guidelines. Then Geoff and Matt will present a deep dive into a sample application using the webOS Clock app. Geoff will review Clock’s UI design followed by Matt who will show how the Clock app was developed with examples from the Clock’s code.

12:15-1:15 PM Getting Started with Palm® webOS Apps, PART 3: Developer Showcase.

Ben and Dion with Chris Sepulveda (Pivotal Labs), Lawrence Davison (Mark/Space), Alex Pachikov (Evernote), and Dan Kurtz (SelfAware)
Four developers with apps in the Palm App Catalog demo their work and talk about how they got started with webOS. Hear about the challenges they encountered along the way and how they met them, and find out how each of them used skills developed writing for other environments to decrease the webOS learning curve.

1:25- 2:25 PM Getting Started with Palm® webOS Apps, PART 4: Working With Palm: Tools, programs, and app distribution. Ben and Dion with Stephen Feaster, Palm Developer Technical Support

Get ready for the webOS coding workshop Monday night by watching us demo the Palm Mojo SDK to build, debug, and run a simple app. Also, learn about Palm’s developer program and app distribution plans.

7:00-9:00 PM Coding Session: Up and Running with the Palm® Mojo™  SDK

Palm Developer Support Engineer Steven Feaster and other Palm resident webOS experts lead an informal workshop to help you get started with webOS app development. Palm’s staff will be there to provide individual and group hand-holding and instruction as you get up and running on webOS. Bring ideas for cool mobile apps and a wide open mind. And be sure to bring your laptop with Mojo SDK installed,please. To get the SDK, go to developer.palm.com and follow the signs to download. Food and cold beverage will be served!

TUESDAY

12:15-1:30 PM Palm booth in the main exhibition hall

Come see Palm staff during lunch. Get your hands on Palm Pre and Palm Pixi, and say hello to Ben, Dion, and others from Palm engineering and developer relations.

6:30-9:00 PM Dinner reception and Palm booth

Same as above. See you there!

WEDNESDAY

12:00-1:15 PM Palm booth in the main exhibition hall

We’ll be back at the booth during lunchtime.

1:15-1:45 Palm Keynote Address: The Future of Web and Mobile, Ben and Dion

Palm’s developer relations codirectors share their vision for the future of computing and the convergence of web and mobile technologies.

It’s not too late to register. Go to http://sprintadp09.com/sprint_ADP. html

This just in: Palm Software CTO will be joining Ben and Dion Monday morning at the Sprint Developer Conference to deliver a technical overview of webOS. This is a great opportunity to get Mitch’s latest insight into webOS and writing webOS apps.

Later that morning, you can also hear from members of the Palm’s HI and engineering teams talk about webOS HI and app design. They’ll go way  under the covers of one of the shipping Palm apps to show you the ins and outs of how its functionality is written.

We’ll have complete details of what we’re up to on Monday at the conference — including more info about the coding session we’re hosting that evening (and yes, there will be food and cold beverage) — by tomorrow, so check back then.

If you’re going to be in Santa Clara for the Sprint Developer Conference, don’t miss it. If you haven’t registered yet, go to http://sprintadp09.com/sprint_ADP. html

We’re preparing Pixi to be available in time for the holidays. Are you preparing your applications for Pixi?

If you haven’t looked at Pixi, you can find details of the Pixi announcement here. We want to encourage all webOS developers to build your app to run on both Pixi and Pre, adapting as necessary to work properly and look good on both devices.

There are  only two significant differences between Pixi and Pre:

• Pixi’s display resolution is different - it’s 320×400 pixels, as opposed to Pre’s 320×480
• Pixi doesn’t have WiFi

Designing for different display resolutions

The display resolution difference will affect some applications more than others. If your application presents content and interface elements in a list-like or vertically stacked layout and makes use of Mojo widgets, you shouldn’t have to do much to support Pixi.  On the other hand, if your app is designed to fill the screen, you will need to approach your layout with flexibility in mind. To help you do this, Palm’s Human Interface team has prepared a document that you can find at http://developer.palm.com/images/palm/pdf/flexibility_responsiveness.pdf.

To test your app at the new device’s resolution, you’ll need to configure the Palm Emulator to run at 320×400. This page explains how.

Designing your app to work without WiFi

With rare exceptions, Pixi’s lack of WiFi should not affect your application. WebOS apps should be designed in such a way that they operate well in a WAN-only scenario, since even users with WiFi-capable devices are frequently not connected to a WiFi network. If you want to alter your app’s behavior based on the presence/absence of WiFi at any given time, you can use the Connection Manager API to check whether a WiFi connection is active.

Applications that fundamentally depend on WiFi such as desktop sync apps will need to be rearchitected to work without WiFi. If rearchitecting is not a viable option for a particular application, then that app may simply not be a good fit for Pixi at this time and we encourage the developers of those apps to recognize this and inform the user appropriately if they try to run the application on a Pixi device anyway. We also recommend that limitations are documented in the App Catalog description to prevent the disappointment of a user downloading an app they can’t use.

Greetings, webOS developers!

On September 28th, 2009 we updated the Application UI Checklist, which you should use to cross-check your app’s UI before submitting it to the App Catalog. The checklist is mainly intended for standard applications, to ensure that they work, look and feel like other standard webOS applications. But there are other kinds of applications – apps that provide an “immersive, customized” user experience, like what we commonly see in games. Does the UI Checklist apply to those apps? We’ve been asked that a lot lately.

While reviewing “immersive applications” over the last few months, we’ve noticed that:

• Immersive app developers commonly use custom controls (instead of standard webOS framework controls).
• Immersive app UI designs (especially for games) are complex, and commonly contain tap targets that are smaller than what we recommend (minimum size = 48 pixels).
• Immersive app developers commonly include buttons in their UI that navigate to different scenes in their app hierarchy, including buttons like “Back,” “Next” and “Home.”
• Performing the back gesture feels “natural” when in Portrait orientation, but not in Landscape.

We’ve given this a lot of consideration and have the following advice for developers who are creating apps that provide immersive user experiences:

Use one style of controls consistently:

• If your app uses custom controls in a scene, use those exclusively.
• If your app uses framework UI controls in a scene, use those exclusively.
• Do not mix custom controls and framework UI controls.

When displaying a standard scene in your app:

• Include required UI elements like the App Menu and its standard items (Edit, Help) and the standard Help scene.
• Support required behaviors users expect, like the Back Gesture.
• Ensure that your app displays banner notifications and popup notifications from other apps, when they occur.

When displaying a scene in full screen mode:

• Provide all the UI controls a user needs to navigate to different scenes in the app.
  • It’s okay to include Back or other scene navigation buttons in an immersive full screen UI.
    • If the fullscreen scene is in Portrait orientation, you must support the Back Gesture.
• Provide visual tap feedback.
  • When a user taps a button, make sure it changes so the user knows the app received the tap.
• Make sure tap targets are large enough to tap.
  • In standard apps, we recommend tap targets be no smaller than 48 pixels. Developers have told us they think this is “kind of big” for game UI’s, where every pixel is precious. If you must use smaller graphics, increase the size of the DIV they’re enclosed in whenever possible, to increase the size of the tap target. Don’t ever make the tap target smaller than 32 pixels, because targets smaller than that are difficult to detect reliably.
• Design your UI to run on each webOS device
  • The Palm Pre is a 320 x 480 pixel device. The Palm Pixi is 320 x 400. Make sure your app runs on each. For tips regarding how you can optimize your design for each device, read the document Designing for Flexibility and Responsiveness.
• Test your app on each webOS device
  • Test your app on the webOS device it’s intended to run on. This is especially important for developers porting apps from other mobile platforms. Try your apps and make sure everything in your UI still feels big enough to tap.

We’re providing these guidelines here for you now, and will add them to the App Checklist in time. For now, you can rely on these as our official recommendations when designing and implementing apps that use fullscreen mode to provide users with an “immersive user experience.”

The Palm UI Design Team