Adam T's blog: Life in the FAST lane

I've never really got on that well with building GUIs on mobile phones. Primarily, it's been the very basic look and feel of components, or the limited options for laying them out on a small screen of undefined size. There are plans afoot to give the mSOA Reference Architecture for CAPS a makeover so that it's more visually appealing, so I've been keeping an eye out for technologies we could use.

I'd heard of LWUIT from JavaOne (I was manning the Hydrazine stand part of the week, literally over the wall from the LWUIT team). Although it's being used in a project I'm involved with I didn't give it much thought until I saw it in use this week.

LWUIT is a GUI toolkit for phones, and other small devices. A lot of the concepts are borrowed from swing, although it's not as complex. The LWUIT homepage has good documentation and some easy tutorials... shouldn't be a problem to knock a test MIDlet together, right?

Here's the NetBeans project - binaries are in the "dist" folder. I've only tested on the WTK emulator and my phone (Nokia N95) by copying the jad and jar files to the device and installing them through the file manager.

Today, someone on a mailing list I was reading asked about how to do Base64 encoding and decoding in Java. Surprisingly, it's not part of the core libraries and although there are a couple of them hidden away they're either private or not recommend for use. Usually I end up googling for an implementation I can use (which may be what you've done to find this page).

I thought that I ought to be able to make my own, so here's the result of a couple of hours of hacking around. Consider it freeware. Use it wherever you like. No warranties. If it doesn't work for you either let me know or just grab another one from the Internet...

Download

Example usage:

  String x = "To the batmobile! Atomic batteries to power. Turbines to speed.";

  // Encode, no linefeeds
  Base64.encode(x.getBytes());
  // Same as the above
  Base64.encode(x.getBytes(), false));
  // Encode, linefeed at 76 chars (MIME encoding)
  Base64.encode(x.getBytes(), true));

  // Decode
  Base64.decode( Base64.encode(x.getBytes()) );

For a long time, I've had this nagging feeling that I should invest some time into learning Lisp. More and more I've been noticing posts on reddit talking about how great a language it is, and how much more productive it is than pretty much any other language. Well, I'm not sure about that; there are a lot of great languages and it's your familiarity with it that makes you productive. But anyway, I'm not a complete novice having done plenty of work with Monk (SeeBeyond's proprietary Scheme implementation from some years back) and I understand the basic concepts and know that it can be used to produce some really elegant code.

So I armed myself with a couple of good books and found some little projects to work on.

Last night I came across a bit of a shocker.

I have a need to generate a short sequence of random numbers. Lisp has a function for generating them. Perfect. Hmmm. Not quite.

Here's a bit of code to print 5 random numbers between 0 and 9. There's nothing complicated about it.

Feeding this short program into GNU Common Lisp produces the following output:

So far, so good. Let's run the program again and see what random numbers it comes up with this time:

Wait a minute... didn't it print those the last time?

OK, so maybe there's something I'm missing. Off I go into the Common Lisp specification. A-ha! There's a global variable called *random-state* which acts as the seed. Promising. But there's no function for setting it to some other value and its structure is implementation-dependent so if you did manage to hack its internal structure directly, you would end up with something non-portable.

The specification does acknowledge this but defends it by saying that "there is no simple way to guarantee that any user-specified seed value will be random enough." In other words, Lisp knows better than you what you want. Then it goes on to say that to avoid repeated invocations of the same program producing the same values, you should write the *random-state* variable to a file periodically and read it in again every time the program starts. Really? I don't recall ever having to do that in any other programming language.

Now I don't know about you, but I still don't think what Lisp calls random is in fact random. I call it predictable.