Writing apps for the N900, part 3 — touch selectors

There is a contents page for all these posts.

Matters arising from last time: There’s been some very helpful feedback:

• Colin Watson pointed out that debhelper 7 makes building debian/rules files far, far simpler. But Jonny Lamb told us that Maemo doesn’t ship with debhelper 7.
• A Nokian emailed me to point out that in Maemo 5, application icons should be 48×48, and that 26×26 is from Maemo 4. (26×26 will still work, though, as we saw.)
• Several people pointed out that the “B” in “XB-Maemo-Icon-26” stands for “binary”.
• And someone on Reddit said that “raeddit” is not a particularly wonderful name. This is true, and I’m open to better suggestions. I didn’t want to call it “reddit” without asking the reddit admins!

Today we’re going to introduce another new widget which is specific to Maemo.  The program currently opens the target site when you click a link. Last time, we promised to make it put up a menu of possibilities, instead:

Selectors. This is called a HildonTouchSelector, and it pops up (so to speak) all over the place. It can live inside any window, but it also has its own special kind of dialogue called a HildonPickerDialog.  It’s very like a combo box, but much easier to use with your fingers.

You see that the program behind the selector is blurred out: that’s to show that it’s not available. If you were to tap the blurred area, the selector would close without making any choices, and you would return to the rest of the program. You can also see that the switcher button at top left is not blurred: that’s because the selector is only modal, not system-modal. You can’t interact further with this program until you deal with the selector, but you’re free to switch to another program or start a new one.

What do we actually need? Now, before we dive into coding, let’s think about what we need from any representation of one of the lines in the menus.

• We will need to ask it for the text to appear in the menu.
• And it should be able to decline to appear in the menu.  For example, “vote up” should only appear if you’re logged in.
• We will need to ask it to deploy, if it’s chosen.

How could we best implement that?

• The fairly elegant way would be a set of singleton classes all implementing a common interface.
• The very elegant way would be a set of DBus services.  That way, third parties could come along and add new menu options.
• And perhaps we’ll do it the very elegant way later.  But this is a quick and simple tutorial, so…

We’ll use a set of callbacks.

• Each callback takes a representation of the post, and a boolean– true if we’re preparing, false if we’re deploying– and returns a char*.
• If we’re preparing, the char* is the name that will appear in the menu, and should be freed by the caller.
• But if we’re preparing, the callback may also return NULL, to decline to appear in the menu.
• If we’re deploying, the callback should always return NULL.
• We promise not to ask a callback to deploy if it returned NULL in the preparation stage.

A small amount of extra work brings us to raeddit-05 (diff to raeddit-04, git cloneable, and available from maemo-extras).  This contains two callbacks: one to visit the actual site, and one to visit the comments page on reddit.  It looks like this:

It’s already much more useful this way, but it’s looking a bit bare with only two entries.  Clearly we can’t put in “vote up” or “vote down” until we allow the user to log in. We could easily put in the ability to buy a shirt, but there seem more important things to do first.

For example, every good mobile application needs a “share” button.  So next time we’ll be looking at how to add an entry which lets us IM or email the link to our friends, or post the link to twitter or identi.ca.