Chris Hatton's Projects

I recently made a post about J2MEPolish, but have since made the decision not to use it and go with LWUIT instead. JavaME’s core UI support consists of the lcdui package and not much else; which is very basic and looks-wise not what your clients are going to expect in 2010. Which begs the decision of which 3rd party library to use. The choice has not been clear cut, and from what I can tell J2MEPolish was the best offering for a number of years. However when I started to use it, I found the build process it uses to lack the claimed compatibility with recent versions of both Eclipse and Netbeans. Furthermore, when making posts to Enough softwares forum, answers weren’t forthcoming and from what I can tell the project seems to be losing steam. Not a good starting point when using any technology.

Enter LWUIT, until recently the pet project of Shai Almog, a developer at Sun, this library has just made its status as an official Sun JavaME API. It’s approach of following the Swing model where practical, being code-centric and being supplied with a nice cross-platform Resource Manager for packaging fonts, styles and other files makes it immediately attractive and usable by any Desktop UI developer. I was happily coding right away and got further in half a day than I had in three with J2MEPolish. Its graphical effects look as thought they could be heavy for older phones, so if backwards compatibility is important to you this is worth consideration. For forward-looking proejcts on increasingly powerful modern devices, though, LWUIT offers a pleasing opportunity to make genuinely modern looking Java MIDlets.

Importantly, the project is in active development with version 1.3 due for release soon, supporting more Layout Managers and with fully implemented on-screen keyboard amongst other improvements. If you’re trying to choose a UI library for your next JavaME project, I would strongly recommend checking it out. You can start at Shai Almog’s blog, here: http://lwuit.blogspot.com/

I just had After Effects crash on me because of a problem rendering a frame. Yeah, It happens… The ‘last chance to save’ feature kicks in, allowing me to save my project. Phew, all’s well. But then, half way through the ‘last chance’ save After Effects decides it would be a nice idea to update the UI for me(?) which means re-rendering that frame, crashing again, reporting an inconsistency because its already saving the project (well, duh), and totally dieing. Adobe FAIL.

…and because I recently reinstalled After Effects, the normally brilliant 5-minute autosave feature that would have saved me from this much pain is, of course disabled by default. WHY? Idiots!!!

To top it all off I didn’t even want to render the frame I skipped to, I was just getting the playhead out the way.

I need coffee, this is going to be an extended working day

I’ve started using the J2ME Polish library in a JavaME project since using the default lcdui interface library isn’t a realistic choice for anything but the most sparse utility applications. J2ME Polish is more than a replacement UI library: it’s a build process which allows the developer a smooth upgrade path from their existing lcdui based code, beginning with the insertion of style directives which J2ME Polishes build process turns into additional java code just before javac get’s busy. The ability to make these directives conditional, and based on separate style sheets also eases deployment across different devices. Its a clever scheme, using Ant, but this does come at a cost; it is very fussy about its running environment and, unless you are already very experienced with Ant, some aspects of it can be bewildering. It’s clearly not plug-in-and-go software, so developers have a fairly steep learning curve before its power is unleashed. I’m going through my own trial-by-fire with it now; so here are some handy notes for anyone up against the same issues (including myself, later, when I forget ):

Adding JAR Libraries: If your project references another JAR (one that isn’t part of the MIDP, CLDC or the J2MEPolish library) you’ll quickly discover that adding it to the project build path in Netbeans or Eclipse, in the normal way, is ignored by the J2ME Polish build process! Since the Ant build script controls the build process, it’s natural to look here next for an obvious ‘classpath’ entry, but theres no joy to be had here either. After much Googling, I found the answer is to add an attribute called binaryLibrary to the <build> element of the Ant script, in build.xml, like so:

<build
symbols=”ExampleSymbol, AnotherExample”
fullscreen=”menu”
usePolishGui=”true”
binaryLibrary=”/home/user/NetBeansProjects/exampleProject/kxml2-min-2.3.0.jar”
workDir=”${dir.work}”
>