Hey, it’s working! \ud83d\ude42 I ironed out the problems I was having with my J2ME Recipe Viewer application. Couple things I did to make it purr:<\/p>\n
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<\/a> phase (where I could System.out.println) to the actual phone. So I created a Form<\/a> that took a String<\/a> message as an argument to the constructor and then appended the String to the Form. Then in the two Thread<\/a> 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<\/a>, you can download the code<\/a>) to pop that form to displayable:<\/p>\n midlet.displayManager.pushDisplayable(new FormError(midlet, error.toString()));<\/p>\n Second, I noticed that the getType() method of the HttpConnection<\/a> object wasn’t returning “text\/xml” like it was on the emulator, instead it was returning <\/p>\n “text\/xml;Charset=us-ascii”<\/p>\n 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:<\/p>\n if (code == HttpConnection.HTTP_OK && type.equals(“text\/xml”)) {<\/p>\n 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! <\/p>\n 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<\/a> 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<\/a>: “Advanced MIDP Programming: Developing High Performance, Highly Responsive Wireless Applications<\/i>” [download the pdf<\/a>, 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. <\/p>\n 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.<\/p>\n You can download the updated J2ME app and source:<\/p>\n RecipeViewer.jar<\/a> Hey, it’s working! \ud83d\ude42 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 … Continue reading J2ME Recipe Viewer update & code samples<\/span>
\nRecipeViewer.jad<\/a>
\nRecipeViewer source<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"