dasman’s World

With my recent interest in J2ME development, I found the time to download Netbeans and the J2ME Mobility pack. I have to say I’m quite impressed.

I’ve downloaded both version 4.1 and the 5.0 Release Candidate (RC2). One of the first things that impressed me is they both perform quite well on my (slightly …mature) laptop. Once things start up, its all quite snappy. I can find Eclipse a bit laggy at times. Of course I haven’t really put these tools through their paces yet with any advanced projects – this is really just a summary of my first inspection.

The big drawcard though (for me) is the Flow Design screen. Here’s a sample screenshot:

Basically, this tool helps you set up the skeleton of your applications. You drag all the different screens onto your workspace, and connect them to illustrate program flow. For example, the default project comes with a “Hello World” program that has an exit option. The screenshot above shows me inserting an “Are you sure?” screen when a user chooses “exit”. So, the exit option now connects to the new screen which presents them with OK and Cancel options. Cancel directs you back to last screen and OK takes you to the “Exit” state. Took me 20 seconds.

This is a great idea for mobile development – compared to a Swing application, a mobile app is likely to have large number of different screens/forms that all interconnect due to the limited screen real estate. This feature really takes the drudge out of that.

You also have a Screen Designer for placing widgets (“Items”) on your screen. Also great, although not as ground breaking as you may think – J2ME’s layout capabilities are pretty simple, so there’s less advanced formatting required (or even possible!). Very handy nontheless.

Once you have your rough architecture sketched out, adding your code is pretty straightforward – the generated code is reasonably clean and well thought out. Versions 4.1 and 5.0 differ slightly in their approach as to how you integrate your custom code:

• In version 4.1, the generated code is “locked” and uneditable. One of the forms allows you to insert some code in the generated sections (with which you might do a “callMyMethod()”). You can then go to the code view and fill out the implementation. This feels a bit limited, especially as the form doesn’t seem to be able to do intelligent auto-complete.
• In version 5.0, the generated code is “kind of locked” . You can’t change it, but you can add to it. So, you generate your code structure, open it up in the source view and add whatever behaviour you want.

(At least thats the way it appears after a 15 minute look, without reading any of the help doco!)

I think it all looks pretty cool. The biggest thing holding me back is that I’m an eclipse guy, so I’ve got a bit of a hurdle getting used to the new user interface, keyboard shortcuts, etc. But its compelling enough that I’m going to have go at using NetBeans as my J2ME development tool, while still keeping Eclipse as my normal Java IDE. I’ll keep you posted as to how I go…

Typically, I work in Java. When I’m not working Java, I’m working Perl. Sometimes I even do work in Prolog (no, really!). But once in a while I venture into the C++ world.

I’m not a fan. Having my classes split across multiple files. Having the parent class decide what I can and can’t subclass. Trying to decide whether the caller or callee has responsibility for deleting an object. That said, there is a Perl-ish “Theres More Than One Way To Do It” (TMTOWTDI) thats kind of nice.

But with all the complexity inherent in a C++ program, documentation is all the more important. A work mate put me on to doxygen. It can be summarised as Javadoc for C/C++. Technically, its more than that – it can handle a range of languages and input files (even Java!), but the largest use appears to be the C/C++ arena.

Just like Javadoc, you create special comments throughout your source code, which get turned into documentation. And, you can insert special directives in these comments which have special meanings. Some favourite examples are:

• @todo to flag a To Do item – your documentation will include a TO DO page summarising all these items
• @version to detail what is in a particular version
• @bug to flag a bug. Again, your documentation will include a bug page summarising all flagged bugs

In some ways, Doxygen is more powerful than Javadoc, out of the box. It can generate HTML and LATEX formats (Javadoc can do LATEX, but you need a custom doclet). The default pages show the class hierarchy, as well as providing links to the source code, neatly colourised and formatted. And most impressively, it can integrate with DOT from GraphViz to do graphical representations of the class hierarchy, as well as simple “has-a, is-a” type diagrams.

The flexibility comes at a cost – typically you have a big config file to tell Doxygen how to run (It reminds me of the “less is more” nature of Java versus C++ – Java may have less language features, but is more straightforward to debug and use as a result). And the nature of C++ in particular, with a class definition spread over multiple files can make some of the documentation decisions tricky: Do I put the method summary and method detail in the header file, or the cpp file? Or one in each? Whichever I pick, I always end up swearing once a coding session and having to flip around source files to find the info I need.

Niggles aside, this all makes C++ programming a lot more manageable. On larger projects, I can hand over the source to another developer and know they have reasonable documentation from the start. And on smaller projects, I can keep track of the issues, and architecture more easily. If only my IDE supported it, like Eclipse supports Javadoc….

I’ve been playing around with some J2ME development lately (thus my earlier posts on Sudokulet). The whole process has been pretty painless, thanks in large part to EclipseME.

EclipseME is a plugin for Eclipse to let you use Eclipse for J2ME development. And it fulfils my idea of a good design by changing very little about my Eclipse experience. I use Eclipse like I always do – its just I’m using a different set of APIs and the end result will run on a mobile phone. But all the normal Eclipse-y things like refactoring, etc work as normal.

As well as making J2ME “just work”, it also simplifies some of those tasks specific to J2ME. JAD files in particular (which are used to describe various aspects of your J2ME Midlet) are given a special editor so you don’t have to worry about the format of this file, or its various permitted keywords.

Also of great use is the new right menu option “Run on Emulator” (and “Debug on Emulator”). Its really handy to be able to do this from within Eclipse, rather than have to get out of the zone (and the IDE). That was one thing that used to drive me crazy in my old days when I used nothing but the Sun Wireless Toolkit to develop in.

(A note for new players – you still need the J2ME libraries which you can get from Sun, but also from various mobile vendors like Nokia, Sony, etc. The vendor SDKs also include special emulators that are more “true” to their particular phones. EclipseME supports a variety of these, and I’ve never found one that I couldn’t get to EclipseME to play with at all. However with at least one version of the Nokia SDK, I couldn’t get the “Run in Emulator” to work. It wasn’t a total loss though – I configured a “Run External Tool” setting to accomplish almost the same thing).

The development of EclipseME is nice and active, and it also integrates with other tools. ProGuard can be used in particular to obfuscate (and thus shrink) your J2ME midlet – which gets all the more important on limited storage mobile phones.

So, well worth checking out if J2ME is an area you want to get into. Its not the only option though – in particular I’m reading great things about NetBeans with the Mobility pack. As I understand it, this offers a slightly different model of graphically showing you the Midlet’s life cycle – giving you the option of more of a graphical based development process. I hope to get some time to play with it – expect a post soon! And Nokia are getting into Eclipse in a big way – an Eclipse-based tool for developing native C++ code is due out soon, and theres been talk of them contributing J2ME tools to the core Eclipse project.

Sudokulet (a Sudoku solver for mobile phones) has now been upgraded to version 1.1.

The changes are pretty minor:

• A proper “Exit” option. Some Nokias automatically add an exit option to a J2ME midlet but many devices do not… There is now always an exit option
• An “About” option to get the version information, and web address for the product

The program is still free, although you have the option of making a small donation should you be feeling generous!

As before, it can be downloaded from the AITC web site at http://www.asman-it.com.au/products.html

AITC has just made available the first version of “Sudokulet” – a Sudoku solver (and player) written in J2ME which, for the layperson, means you can run it on your Java-enabled mobile phone. At last, a use for the pesky mobile phone!

You can get it from http://www.asman-it.com.au/products.html.

Its an early version, but hopefully some people will find it useful, or at least entertaining for a short while….

(And the observant will notice that the 6 year old Asman IT website has changed its look. I can’t really claim its changed for the better, but at least its different! And, thanks to the complete absence of colour, should you ever choose to print out a page, you won’t run out of one particular colour in your print cartridge )

When the new Eclipse came out, I rushed to the Net to download a copy, unzipped it to the hard drive…. then promptly did nothing with it!

Now, almost a week later, I’ve finally started using it in anger. Nice – very nice. I’m not running on the latest and greatest hardware by any means (but then again, the project I’ve just started working on is very small scale at this stage). All that said, it feels really snappy.

I’m particularly impressed with some of the refactorings specific to Java 1.5. In particular, after getting a warning about using a generic “Stack” object, I was able to use the built in refactoring, and have it detect that I always populated the stack with “File” objects. A quick preview to check it had, in fact, done the right thing, and voila – the type definition was ameded to Stack and all my manual casts removed.

Things like this really speed up that learning curve (or perhaps, more accurately, “familiarisation curve”) for new language features. Once again, Eclipse doesn’t disappoint….

So, finally got around to playing with JRobin, and I’m pretty impressed. To those who don’t know, JRobin is a re-implementation of RRDTool, a data storing and graphing utility, in pure Java (The original is your standard configure, make, make install C jobby).

Anyone who has worked in Network Management has almost certainly encountered RRDTool – its a nice generic tool to store arbitrary numeric data without having to worry about files growing without bound, due to its trick of being able to aggregate data as time goes by. Because of its command line interface, it can be grafted into any little sysadmin script to produce graphs on pretty much any aspect of a system.

I’ve been a big user of it in the past, mainly with Perl. RRDTool comes with Perl bindings which makes it pretty convenient. Similar bindings have existed for Java, but the need to manually compile up RRDTool for your particular platform has detracted somewhat from the run-anywhere Java thing!

JRobin is a re-implementation of RRDTool in pure java. So, bundle the JAR up and it should just work, no matter where your application runs.

I’ve just hacked together a quick app that reads in a log file and produces a graph, and the process is pretty painless. Loading up my log file (of timestamp, value pairs) was done with the following:


while ((line = reader.readLine()) != null) {
StringTokenizer tokenizer = new StringTokenizer(line);
long time = Long.parseLong(tokenizer.nextToken());
double value = Double.parseDouble(tokenizer.nextToken());
Sample sample = db.createSample();
sample.setTime(time);
sample.setValue("temp", value);
sample.update();
}


And producing a JPanel containing a graph is even easier!


RrdGraphDef def = new RrdGraphDef();
def.setTimePeriod(Util.getTimestamp(2004,9,01), Util.getTimestamp(2004,10,4));
def.setVerticalLabel("Degrees");
def.setTitle("Computer Room temperature");
def.datasource("t", RRDFILENAME, "temp", "AVERAGE");
def.area("t", new Color(0xFF,0,0),"Temperature");
def.gprint("t", "AVERAGE","Avg temp: @3@r");
def.setLowerLimit(0L);
RrdGraph g = new RrdGraph(def);
JPanel p = g.getChartPanel();


Pretty straightforward, Huh?!

Now, if its graphs you’re after, bear in mind that JRobin is not designed to produce 101 different types of 3D, animated, translucent graphs – you get a basic line graph, and thats it (although its perfectly servicable, and not unattractive). If you want fancy graphs, you’re better of storing the data yourself and using JFreeChart.

One final little thing, in this already overly-long post. As someone who does a lot of Perl code (and is imbued with some of that culture), I’ve gotta say its refreshing to be able to produce my graph without a single Factory, or Delegate, or Proxy in sight. I mean, don’t get me wrong – I love my Design Patterns – but sometimes you just want to write code. You know what I mean?