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.