Rich Internet Application Realized

Last Thursday we (Mindseye) launched a pretty cool rich internet application: FootJoy MyJoys. MyJoys is the new program from FootJoy that lets you customize the #1 waterproof brand in golf, DryJoys.

There are really two parts to the application: a front end built for consumers and a back end for FootJoy customer service reprepsenatives to enter trade orders and lookup order status, both using Flash and Flash Remoting. The site uses a smorgasbord of technologies: Flash 6 and Flash Remoting .NET, C# and ASP on the server side, SQL Server 2000, wget, rsync, aspexec, Java, FedEx & PGP.

Co-worker Tai and Dave did the all the Flash work, I did all (99.95%) of the server side work.

Creating RSS using Java

I wanted to create RSS feeds for karensrecipes.com using Java. I did my ‘research‘, came to this page: Ben Hammersley.com: Java RSS libraries and then used the RSS4j library to create a servlet that serves up dynamic RSS feeds of the 10 most recently created recipes per category (samples: Breakfast, Soup, Barbeque..).

They syntax is pretty simple, you get an RssDocument and set which version you want to use (RSS 1.0, .9 or .91):

RssDocument doc = new RssDocument();
doc.setVersion(RssDocument.VERSION_10);

and then create a RssChannel object and add that to the RssDocument:

RssChannel channel = new RssChannel();
channel.setChannelTitle("Karens Recipes | Most Recent");
channel.setChannelLink("http://www.karensrecipes.com/3/Soup/default.jsp");
channel.setChannelDescription("The 10 most recently added recipes in the soup category.");
channel.setChannelUri("http://www.karensrecipes.com/rss/?categoryid=3");
doc.addChannel(channel);

Next, you’ll retrieve the items using a database, the file system, etc… and add each item as a RssChannelItem:

// connect to the datasource
// iterate over something (db? vector?...)
RssChannelItem item = new RssChannelItem();
item.setItemTitle(label);
item.setItemLink(link);
item.setItemDescription(description);
channel.addItem(item);

and then finally, using the RssGenerator class, call the generateRss() method, in this case I’m sending the output to a Servlet PrintWriter:

PrintWriter out = response.getWriter();
RssGenerator.generateRss(doc, out);

You could just as easily write it to a file:

File file = new File("/opt/data/rss.xml");
try{
RssGenerator.generateRss(doc, file);
System.out.println("RSS file written.");
}
catch(RssGenerationException e){
e.printStackTrace();
}

Simple. Easy to use.

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

Delegates, Components, and Simplexity on artima.com

Delegates, Components, and Simplexity, great quote:

.. There’s one kind of simplicity that I like to call simplexity. When you take something incredibly complex and try to wrap it in something simpler, you often just shroud the complexity. You don’t actually design a truly simple system. And in some ways you make it even more complex, because now the user has to understand what was omitted that they might sometimes need. That’s simplexity. So to me, simplicity has to be true, in the sense that the further down you go the simpler it gets. It shouldn’t get more complicated as you delve down.

ASP.NET Tracing

ASP.NET has a feature called tracing, which according to the ASP.NET Trace documentation… allows you to view diagnostic information about a single request for an ASP.NET page simply by enabling it for your page or application.” If you’ve used ColdFusion before, you’re probably yawning, “.. we’ve had debugging since version 3.0..”, but wait, it gets cooler. You can also view the information from a page (Trace.axd) called the “trace viewer”, which allows you to view detailed information the last N requests (read: requests that other people have made to your site), which would/could be extremely helpful during any phase of development, including production. Unlike ColdFusion, you configure this per application in the web.config file:

<trace
   enabled=”true”
 traceMode=”SortByCategory”
 requestLimit=”40″
 pageOutput=”false”
 localOnly=”false”
/>

Anyone know if there is a tool like this for servlet containers? Or if certain servlet containers support something like this?