Category Archives: J2ME

Amazon Web Services Newletter cool links

The February Amazon Web Services Newsletter had some pretty cool applications:

Blogfuel: “Use blogfuel to create a link to an individual item at amazon (using ASIN Search) to illustrate your book review. Or place the code in the sidebar of your blog as a “What I am currently reading feature”. You have control over the width, colour, number of columns, image and text size.

PocketBooks – Amazon: “Check prices and availability of books at Amazon.com and Amazon.co.uk from your Java enabled phone

Books of note, from Sybex: Mining Amazon Web Services: Building Applications with the Amazon API and from Dimensions: Google, Amazon, and Beyond: Creating and Consuming Web Services

Ericsson Mobile Positioning SDK

Ericsson released beta 2 of their MPS SDK, which is a software development kit for developing location based services on wireless phones. According to the site:

“It supports both the Ericsson proprietary Mobile Positioning Protocol (MPP) and the Mobile Location Protocol (MLP). MLP is the standardized interface between a Location Based Service application and the Mobile Positioning System.”

You can download the SDK here (requires login).

J2ME Recipe Viewer update & code samples

Hey, it’s working! 🙂 I ironed out the problems I was having with my J2ME Recipe Viewer application. Couple things I did to make it purr:

First, I mentioned that I was getting an IO error when trying to make a wireless connection using the phone, it became apparent that I needed way better error handling in the application once it moved from the WTK emulator phase (where I could System.out.println) to the actual phone. So I created a Form that took a String message as an argument to the constructor and then appended the String to the Form. Then in the two Thread classes that I used, if I got an error, I’d simply add the error message to the Form and use the DisplayManager (from the Core J2ME book, you can download the code) to pop that form to displayable:

midlet.displayManager.pushDisplayable(new FormError(midlet, error.toString()));

Second, I noticed that the getType() method of the HttpConnection object wasn’t returning “text/xml” like it was on the emulator, instead it was returning

“text/xml;Charset=us-ascii”

which means that the AT&T proxy is messing with the response header that I’m sending from my webserver. Because my logic looked like this:

if (code == HttpConnection.HTTP_OK && type.equals(“text/xml”)) {

after attempting to connect to my web server, I was never able to get to the XML parsing and subsequent handoff to the next screen. Anyway, I removed the check on the type (why did I have it in the first place? I don’t know…) and then everything worked!

After I got it working on the phone, I wanted to fine tune some of the other things I thought were kludgy about the app. Both the ListRecipes and ListCategory classes (which both extend the MIDP List class) presented a list of choices to the user and then on select would do two things: a) they would present an Alert to the user and then b) would start a Thread responsible for making a wireless HTTP connection, which itself would then redraw the screen with the result of the HTTP connection. The thinking behind this is probably common sense to someone who’s been developing non web-apps for some time, but it was something that I learned about while sitting in the back row of TS-2037: “Advanced MIDP Programming: Developing High Performance, Highly Responsive Wireless Applications” [download the pdf, it’s got 91 very useful slides on MIDP UI]. The problem with this approach is that the Alert dismisses itself after a set period of time (in this case 3 seconds) which resulted in a weird user interface. You’d select “Breakfast”, see an alert for 3 seconds, see the recipe categories again, and then a couple seconds later would see the breakfast recipes. So instead of an Alert, I created another Form that took a String as an argument to its constructor and then displayed that Form… which would not dismiss itself and then let the Thread take care of redrawing the screen.

Finally, I updated the search form that it too starts up a Thread, which connects to the webserver, which returns XML and then displays a list of matching recipes.

You can download the updated J2ME app and source:

RecipeViewer.jar
RecipeViewer.jad
RecipeViewer source

J2ME Recipe Browser

As an exercise, I wrote up a J2ME client for Karensrecipes.com. As I mentioned a couple days ago, it sends HTTP requests to a servlet to receive a list of recipes as XML, and then (given a specific recipe), sends another HTTP request for the recipe details (again returned as XML). It works great on the emulator, not so good on the 3650. It looks like the phone can’t establish a connection to my server, because as I tail the Apache logs, I don’t see the request come through (I do see the request when using the emulator). I’m guessing it has something to do with the default connection for Java apps on the phone. Anyone have any experience with making wireless connections on the 3650 through J2ME?

If you’re interested, you can download the application and the source:

RecipeViewer.jar
RecipeViewer.jad
RecipeViewer source

Parsing XML in J2ME

Spent a couple hours tonight working on a MIDP client for the recipe site. Initially I tried serving up pipe delimited plain text (ie: response.setContentType(“text/plain”);) and then parsing that using the J2ME classes, but then I saw the light that is XML, in this case kXML. kXML “… provides an XML pull parser and writer suitable for all Java platforms including the Java 2 Micro Edition (CLDC/MIDP/CDC). Because of its small footprint size, it is especially suited for Applets or Java appications running on mobile devices like Palm Pilots or MIDP enabled cell phones.” I’ll post some code after I’m done with it, this article is a great introduction.

J2ME StopWatch UI improvements

At Mindseye they gave us every other Friday off during the summer, so naturally I spent the time programming (it rained today in Boston, couldn’t go outside). I did get some feedback from people who installed and/or used the StopWatch app that I released last week. One of the obvious things was allowing the user to start and stop the stopwatch using what is commonly called the “FIRE” button on a phone. Turns out this is relatively easy to do because I was using the Canvas class to paint the screen. The Canvas class is (according to the documentation) “… a base class for writing applications that need to handle low-level events and to issue graphics calls for drawing to the display.” Low level events include things like key press events, pointer events, and game actions. Anyway, long story short, I added the following code to the StopWatchCanvas class constructor:

fireKey = getKeyCode( FIRE );

and this method:

protected void keyPressed( int keyCode ){
  if( keyCode == fireKey ){
    if (thread.isPaused()) {
      // get the thread out of paused mode
      thread.startWatch();
    } else {
      thread.pauseWatch();
    }
  }
}

The first line uses the getKeyCode(int gameAction) method of the Canvas class to retrieve the int value of the gameAction, which in this case is the static variable “FIRE“, also part of the Canvas class.

The keyPressed() method then listens for any and all key pressed events and calls the appropriate method in my thread class to start or stop the watch depending on what state the watch is currently in.

Couple interesting observations about this:


a) if I used one of the high level UI components to paint characters to the screen (like the Screen, Form, Item, etc. classes), I wouldn’t have been able to listen for key events (let me know if I’m wrong about that J2ME experts), so it was easy to do only because I was extending the Canvas class.

b) the options menu that is built by using Command objects still works ok. This is important because users who don’t have a “FIRE” button on their phone can still use the application.

The other UI improvement was that I added a custom icon for the stopwatch application. Didn’t find alot of documentation about this, but from what I can tell, the image that you specify in the MIDlet-Icon attribute of your jad file, must be a 24 bit 32×32 png file. Anything other than that didn’t show up on my 3650 (although it did in the emulator). The screenshots you’re seeing in this post show the icon.

The most helpful article I’ve read about the low-level MIDP api’s is “Using the MIDP Low-Level User Interface API” by Eric Giguere on wireless.java.sun.com. Take a peek if you haven’t already.

Download version 1.1 of J2ME StopWatch now!