mobile.java.com launches

Sun’s Mobile Java showcase launched last week at mobile.java.com. It’s not quite what I expected, but I think there’s plenty of opportunity using this distribution channel.

In Sun’s words, "Sun plans to provide a trusted site for consumers to discover, purchase and download mobile Java applications and to accelerate global awareness and market growth for the benefit of mobile carriers and developers."

Right now, they look to be more of a Java mobile content portal, where discovery is emphasized most, but I expect that we’ll soon see many more games and applications submitted and verified (i.e. with the "Java Powered" badge), and available for purchase via payment processor Bango.

I’m curious to experience firsthand the process for adding content to their portal, and how it compares to distribution via a carrier. I think this just might be next of my to-do list.

Tags: mobile applications, mobile, Java, mobile development, Sun

Just Another $.50 Toy

I think what I find most amusing about this is that this is the second story of this nature that I’ve read. That crazy claw game is just irresistible to kids. How do they fit up the chute? Is this a case of poor design or poor supervision? This is what I have to look forward to in a few years, I suppose.

Story via Minneapolis-St. Paul Star Tribune

That thing got a Hemi?

I missed this when it was new — then again, it’s not exactly aligned with any of my interests, but how often do you see a Big Wheel outfitted with a Hemi? Ahh, the Big Wheel. Mine had a hand brake that you could yank to do neat fishtails spins.

All contest finalists at Chrysler’s What Can you Hemi site

Tips for Writing Bluepulse Widgets

One of the neat things about the Bluepulse mobile platform is that it makes it very easy to write a mobile application (a widget). In Bluepulse’s case, you write a traditional web application, using whatever flavor server side code you like, and ensure the output adheres to the XHTML subset specified in the Bluepulse SDK.

Because of the ease with which widgets are created, I expect that we’ll see widgets that are created by those who have no previous exposure to mobile development. And because widgets are generally tightly focused, we’re also likely to see widgets created by newcomers to the web application development field.

So I thought some tips were in order. If you’re already familiar with web applications, mobile development, and XHTML, most of these will seem obvious, but hopefully you’ll find one or two points that will be of value. If you have some tips of your own, please add them to the comments, and together we can build a handy document that can be shared with the good folks at Bluepulse, and on the forthcoming bluepulse widgets site (bpwidgets.com).

General

Find an Idea

If you’re looking for ideas on widgets to create, check out the Bluepulse forums and the Bluepulse blog. Some of the widgets described in the blog might spur some creative thinking, and several people have posted widget wish lists in the forum.

Check the Pipeline

You might also want to see if anyone else is working on your idea before you begin your work. The forums and the blog are a start, and Luke Watson at Bluepulse is a good resource. Luke is involved in Sales & Marketing, and also developer relations, so he might be able to tell you what’s in the pipeline.

RTFM

The development kit is short, and it will answer most of your questions, so you might as well read it.

Enthusiast vs. Commercial

There are two categories of Bluepulse developers: enthusiast and commercial. Enthusiasts develop free widgets and commercial developers create fee-based widgets. I’ve attempted several times, but I have yet to figure out how one becomes a commercial developer.

XHTML Format

Syntax Rules

Your web application’s output must be properly formatted XHTML. The primary rules to keep in mind for proper formatting are:

• All tags must be in lowercase
• You must include a doctype
• All tags must be closed (even single barreled tags like <br/>)
• All tags must be properly nested
• All attributes must be in quotes

Watch your entities

Probably the most common mistake is the misuse (or non-use) of entities, and the most commonly misused entity is the ampersand (&).

In XHTML, the ampersand marks the beginning of an entity. An entity is comprised of an opening (&) and closing (;) delimiter, with the entity code in the center. So any ampersand is treated as the beginning of an entity. If the closing delimiter, the semicolon, cannot be found, your document is not properly formed.

This means that a typical query string like: ?&name=widget&id=7 is invalid. Instead, it should be written as ?&name=widget&id=7.

For those of us who use Dreamweaver for UI development, older versions of DW had a helpful and altogether frustrating setting that attempted to rewrite the entities you carefully wrote. Been here before? Go to Edit | Preferences | Code Rewriting and check both encoding options. Incidentally, DW8 has corrected this and has terrific support for CSS. CSS support is alone worth the price of admission.

Validation

If your widget runs fine while testing it in your browser, but you receive “Unsupported Page Type” errors when running it through an emulator, your XHTML is likely formatted improperly. There are a number of validators out there that will help you make short work of finding the problem. View the source via your browser, and paste it into a schema validator like the one found at http://schneegans.de/sv/. It should point you right to the offending part of your document.

Double List View

At a glance, the double list view appears to be a powerful way to display summary text to a user. On the top line, place your title, and on the second line, place a longer text summary.

Unfortunately, the majority of the devices I tested on did not support the double list view, which limits the utility of it. If something is important, make sure it’s on the top line. If it’s not important, you can place it on the second line, in which case most of the text will be truncated for phones that don’t support the view. My preference is to stick with the regular list view, and support all handsets consistently, according to the bluepulse spirit.

Use Templates

I’m not a big fan of developing UI’s. I’m not that good at it, either. One of the things I like most about developing widgets is that I never have to worry about the UI. I have several templates created: list view template, text form template, and text template, and I reuse them for every page in every widget that I create. I’d recommend that you do the same.

More information on XHTML:
http://www.w3schools.com/xhtml/

Emulators and Testing

Developer Suite

I might be in the minority, but I have always had difficulty installing and integrating emulators with my IDE of choice. Nokia’s Developer Suite installs smoothly and offers 40, 60, and 80 Series emulators, along with the ability to plug-in other Nokia emulators.

International Character Support

In two widgets that I created, Ebay OnTheGo and Amazon OnTheGo, international characters and currency symbols (e.g. yen, pound) resulted in “Unsupported Page Type” errors via Bluepulse during testing.

The quickest way around this (from a performance perspective) is to use regular expressions to filter out the offending characters. I have a couple utility methods that I use for this purpose. One returns a Boolean, and one returns a clean string.

For example, calling checkRegExp(shaun@bpwidgets.com, “[^a-zA-Z0-9]”) returns true, and calling cleanRegExp(shaun@bpwidgets.com, “[^a-zA-Z0-9]”) returns “shaunbpwidgets.com.”

public static boolean checkRegExp(String value, String regexp) {
Pattern pattern = Pattern.compile(regexp);
Matcher matcher = pattern.matcher(value);
if(!matcher.find()) {
return false;
}
return true;
}

public static String checkRegExp(String value, String regexp) {
Pattern pattern = Pattern.compile(regexp);
Matcher matcher = pattern.matcher(value);
if(matcher.find()) {
return matcher.replaceAll(“”);
}
return value;
}

Peter from Bluepulse has an additional handy tip regarding character support:

“If you make sure all special characters are UTF-8 encoded, you can include pound signs, vowels with funny lines/dots and more. Some phones, particularly Nokias, allow the user to type these characters into a Text Form View, so if you use that view, you should be prepared to deal with them.”

Test on Multiple Emulators

Bluepulse takes much of the concern out of this. If it works on one emulator, it should work on them all. This is in stark contrast to the field you play on when developing a typical mobile application! Even though the widget will likely work across all emulators, you might be surprised to see how it looks across different emulators. As a sanity check, see what your widget looks like in several different emulators. You’ll likely find yourself rearranging menu items, editing screen titles, and reworking text here and there.

Test on a Real Device

Similar to testing on multiple emulators, you should test your widget on one or more real devices. Emulators will primarily point you to UI differences between phones, but testing on a real phone might open your eyes to some performance implications of running your widget. It’s also nice to see how your widget will look on the phones with which you are most comfortable – your own.

Traditional Mobile Development Tips

Constrained Resources

Always be aware that users will be using your widget on devices with limited display and data transfer capabilities, and data input is only slightly more amusing than shaving with a cheese grater. Most of the tips in this section follow this constrained resource theme.

Titles and Text

The amount of text that will appear in certain views is limited. For example, in the text-form view, long strings are truncated. Short, terse instructions are better than incomplete instructions.

Menu item title display is generally left to the implementation, though I’m not sure if bluepulse has done any work around standardizing. In traditional mobile development, both short and long labels can be provided, and the implementation decides which one to use. To be on the safe side, try to keep your labels one word long, and front-load them.

Similarly, your screen titles might be truncated, so put the most important characters at the beginning. This has improved dramatically over the years, but not so long ago, it was a real art to determine how to intuitively name your functions or screens with as few characters as possible.

Less important, but still advisable, is to make the first characters of your labels unique from other labels. This will enable users to easily differentiate among the commands available to them. Also keep in mind the potential items added to the menu by the bluepulse client, and ensure that there are no naming collisions.

Use the title of a list page to tell users what to do with that list.

Provide Reasonable Defaults

• Rather than requiring text entry, allow users to select from a list, if at all possible.
• When using lists, offer the most popular choices near the top.
• If your list only has one item, what’s the point of having a list? Just drop users to the action page.
• If you are forced to use text boxes for data entry, provide a reasonable default value.
• Whatever value a user types into that box, save, and present to them as the default the next time around.
• Persist data in a database between visits, rather than asking the user to enter it again on the next visit.

Provide Reasonable Navigation

On any page within your widget, anticipate where your users might want to go next. Provide direct navigation via the menu, rather than requiring the user to back out of an interaction. At the same time, make your widget back friendly, for those who love to mash on those back buttons.

Conclusion

That’s about all I can think of off of the top of my head. As you can see, Bluepulse takes most of the headache out of widget development, but there are still some considerations we all should all keep in mind.

Tags: Bluepulse, widgets, cell phone, mobile application, mobile development, mobile 2.0, bpwidgets

P.B. Loco — So you like Peanut Butter?

Someone, and I won’t mention names, got me preoccupied with chocolate, candy, and all things sweet and delish. By happenstance, a friend forwarded me a link to P.B. Loco. Heard of them?

Let me hit you with a few recipes:

• LOCO COCO: Dark Chocolate Peanut Butter, Raspberry Jam & Coconut
• CINNY NILLA: Sumatra Cinnamon & Raisin Peanut Butter, Vanilla Cream Cheese, Granny Smith Apple Slices & a Drizzle of Caramel
• RAZZLE DAZZLE: White Chocolate Raspberry Peanut Butter, Marshmallow Spread & Sliced Bananas

Peanut butter lovers rejoice, and check out P.B. Loco.

Mozes: SMS-based Mobile Service

You’ll have to put me in the “I don’t get it” crowd when it
comes to Mozes. I’ve used it several times since Friday, and I’m confused with
what exactly (or even approximately) it does.

They describe their service as “a mobile services platform
that connects people with information that matters to them. Mozes consists of
two parts: (1) user accounts, where users can take advantage of unique mobile
services to manage and share their online and offline information and (2) a
design studio, on which any person or advertiser can design, create, and manage
compelling mobile services.”

After I figured out that you had to first use the service
before you could get an account, I tried out their Amazon service. It allows
you to text an ISBN number, and receive back a message with Amazon’s average
rating. Each book you lookup is added to a bookmark list that you can view with
a web browser.

This functionality is a subset of what I put into a
Bluepulse widget I created a few months back. The free widget (Amazon OnTheGo,
available in the “Free” category) allows you to search by keyword or ISBN
number, allows you to search across popular Amazon categories, as well as view
details, prices, used prices, read reviews, find similar items, and so on. It
even has a similar bookmarking system, and the widget UI is menu-driven, which
I find much more usable in mobile applications than Mozes’ SMS-based approach.

That said, SMS is normally used for a reason, and that’s because it’s very difficult to
deploy an application to a large number of phones and carriers. SMS is widely
supported and much easier to deploy, so Mozes is usable on a large number of
existing handsets.

Mozes also has a song lookup service, enabling you to get
artist and title information of songs currently playing at several stations in
the U.S. Rounding out the offering seems to be some minor utilities like
creating a task list via SMS, setting up messaging groups, RSS feeds for your
items, and so on.

Aside from that, there is a keyword service that costs $5
per keyword (when released). This looks to be a way that you can push content
found with your keyword to other Mozes users. The content might be a profile,
picture, advertisement, personal message. I saw several references in the Help
section to keywords, and associating messages with keywords, and messages
requiring payment, but I’m rather confused about how keywords work, and for
what they are intended to be used.

Other than the one mention of what Mozes does, I didn’t see
any more references to the design studio, which is what interested me the most.
So, in summary, I’m confused. Mozes seems to be a loosely related collection of
SMS-utilities tied together with an online account. The most promising feature
that I was able to discern is the keyword service, and I’ll be checking in with
their site periodically to see if additional help or details are made
available.

Mozes (Hint: it’s not evident, but don’t try to sign up for a Mozes account. Just message an ISBN number to them, and they’ll send you a confirmation code you can use to create your account)

Tags: SMS, Mozes, mobile application, Amazon, Bluepulse

Checkmates — Yahoo! beta Friend Mapping Application

Yahoo! released “Checkmates” last week, and I haven’t seen it get too much press as of yet. It’s actually a pretty slick application, with an ingenious navigation system.

It’s a mapping application, but its focus is on showing you where your friends are on the map, or more specifically, where your friends are, are coming from, or are going to. Install the application, sign in with your Flickr account, and you’re ready to go. Find your position on the map, and add a pushpin. All of your friends will be able to see your pushpin on their handsets.

Submaps are also supported, so if, for example, you and your friends are all at a large indoor venue, you can mark your place in the building for all of your friends to see. You won’t find many submaps during beta, however.

What I liked most about the application was the paddle-based approach to navigation. Clicking your paddle center brings up the paddle UI. Now you can click paddle right, left, up, or down to move to the selected submenu. Fast and intuitive.

Yahoo! Checkmates is available here

Tags: mobile, Mobile 2.0, J2ME, mobile applications, Yahoo, Checkmates, mapping

Creative Distribution: Pot-laced candy & soda

Toka-Cola, Pot Tarts, Puff-A-Mint Pattie, Stoney Ranchers, Munchy Way, Buddahfinger, Twixed, KeefKat, Double Puff Oreo. . .oh my!

via The Smoking Gun

Bluepulse Developer Profile: Me

Hmm, yes, I know it’s a bit late to link to this post. But I really am not a fan of self-promotion. A few nights ago, my wife learned of this profile, and was rather upset that I hadn’t told her about it, so. . .

Check out the Bluepulse blog for a glimpse at yours truly. And sign up for a bluepulse account, while you’re at it.

Bluepulse: Powerful in its Simplicity

I’ve been using Bluepulse and developing on their platform for a few months now. There seems to be both hot and cold feedback, depending on where you look. Hot feedback is based on what Bluepulse is, and the cold feedback based on what it isn’t. Make sense?

The Bluepulse folks have made some pretty bold claims about device and carrier support, and from what I’ve seen, they’ve done an exceptional job here. One of the reasons their support is so broad is because, conceptually, they’ve created their own custom browser that supports an XHTML subset. This is where I see the bulk of the negative feedback. Bluepulse is really a layer between you and the content / application that you are viewing (the widget), but this is what makes it so powerful.

They’ve built a platform that enables a mobile phone to access and use a traditional web application that adheres to their rules regarding output. Conceptually, it’s simple (technically, I’m sure it’s not), and I think some people are looking for complexity. Much of the positive feedback revolves around this simplicity, and the doors it opens up for the average mobile user.

With device capabilities progressing so rapidly, is there really a need for a lowest common denominator service like this? As a mobile developer, I long for the day when there is consistent support across devices and carriers, but I don’t see it happening anytime soon. Until it does, it’s not device capabilities, but compatibility, that makes the difference, and this is where Bluepulse excels. Add to that the extensibility made possible with widgets, and the convenience of having all of your widgets available in one centralized location, and you have yourself an appealing package.

Of course, it can’t replace the powerful J2ME application that is built for a limited device list, or the applications built on top of a manufacturer’s API, but those applications won’t have the potential reach that Bluepulse has for a while to come.

Check out Bluepulse

Tags: Bluepulse, J2ME, mobile applications, mobile

Next Page »