Archive for the ‘Dev Environment’ Category

SMS message exchange between BlackBerry simulator instances: a very simple demo

If you’re writing a BlackBerry Java application that sends and/or receives SMS text messages, naturally you need to be able to test the application on the simulator.  And naturally the simulator doesn’t really send SMS messages, so you need to know how to get the simulator to exchange simulated SMS messages with another instance of the simulator.

This is very easy to do.  You can do it with the SmsDemo that comes in the BlackBerry JDE’s sample applications bundle — even though the SmsDemo’s JavaDoc seems to imply that you can’t.  If you look in the code of (usually found at C:\Program Files\Research In Motion\BlackBerry JDE <version>\samples\com\rim\samples\device\smsdemo), the JavaDoc says the following:

This program requires the associated server component found in the com.rim.samples.server.smsdemo package under the samples directory in your JDE installation.

That’s not precisely true.  It doesn’t require the server component — it can actually send demo messages from one instance of the simulator to another, as long as you set the sms-source-port of the one to be the sms-destination-port of the other, and vice-versa.  There are just a few quick steps and notes for launching the two instances: Continue reading

Reality vs. best practices (and getting from one to the other)

If you’ve spent any time studying best practices in software engineering, it can be jarring to discover how far the reality of software production often diverges from the ideal.  It isn’t rare to see code in production — stuff that’s critical to a company’s business — that isn’t even under version control, much less documented with bug-fixes tracked to requirements, testing infrastructure in place, etc.

Personally, I like doing reverse-engineering (restoration of lost knowledge) — taking a bundle of mysterious old code and figuring out exactly how it works and what it’s doing, so that it can be upgraded or replaced.  I’ve done it for more than one company.  However (at the risk of cutting down on the need for this sort of work), I’ll tell you that it’s cheaper to fix “free-fall code” while you still have the engineers who designed it on hand, before a reverse-engineering effort becomes necessary.  It’s a little like an old building with electrical wiring that’s not up to code:  replacing all the wiring seems expensive for something that yields no visible results, yet it’s cheaper than leaving the old wiring in place to catch fire and burn the building down.

How does free-fall code get all the way to production?  In my experience, there are a couple of main causes:  Continue reading

Building a J2ME project with Ant

For a basic MIDlet, the Wireless Toolkit’s ktoolbar application is pretty convenient. When you run it and click on “new project” it provides a GUI where you can enter the information that goes into the Jad and manifest files, then it creates the Jad and manifest files for you as well as creating directories where you can place the source code and the resources. Then all you need to do is select project > package > create package, and it builds the MIDlet for you including a Jar file and a Jad file that you can run on the emulator or run on an actual device. It will even create an obfuscated version for you — all you have to do is download proguard.jar and drop it into the WTK’s bin directory for the project > package > create obfuscated package to work.

However, as soon as you want to do anything fancy with your build at all (such as add extra steps for style checking, preprocesing, custom resource building, etc.) it’s a good idea to set up your build process to use Ant.

The nice thing about Ant is that it’s easy to use and it’s easy to extend it to do essentially anything you want. The build process is controlled through XML files which group sets of commands as “targets.” The commands themselves (ant tasks) are just calls to Java classes, so if there’s no existing command to perform some task that you’d like to have in your build process, you can write your own ant task to do it.

A MIDP project has some standard steps (compile, preverify, build the Jad file, write the corresponding Jar), and as you might imagine, other people have already written Ant tasks for all of this. So after installing Ant, the next step for a MIDP project is to download and install Antenna.

All you really need to do to install antenna is to download the jar file and drop it into your ant lib directory. Then the Antenna Home overview page gives you all the details about what ant tasks are available and what are all of the corresponding properties and attributes to set. Personally I like to start with at least one working demo or sample, so I downloaded the zip file containing the sources and samples, and decided to try the “games” example.

The “games” example copies the source files from one of the standard WTK demos (the “Games” demo) and builds it in a separate directory using Antenna. To run it, you just go into the games sample directory and type “ant”. If you look at the build.xml file, you’ll see pretty quickly that if you change the value of the “” property from “Games” to the name of any other project (subdirectory of your WTK/apps directory), you can use this same build file to build another project.

There were a couple of minor changes needed to get it to work. As indicated on the Antenna home page, I had to set my wtk.home property to the actual path of my WTK directory (in my case it was “/home/carol/jme/WTK2.2″). Plus I added a line to tell ant where to find all of the antenna tasks, again as explained on the antenna home page:

<taskdef resource=”” classpath=”full path to antenna jar”/>

There was one strange glitch though. On my first try, it gave me this cryptic error message:

[wtkbuild] Compiling 8 source files to /home/carol/jme/ant/build/classes
[wtkbuild] javac: target release 1.1 conflicts with default source release 1.5

/home/carol/jme/ant/build/build.xml:39: Compile failed; see the compiler error output for details.

This message is annoying because it’s clear there’s some sort of version number conflict regarding the compilation step “javac”. But version of what? I thought maybe my JAVA_HOME variable was messed up again or maybe there was a problem with the classpath or some other environment variable, but since my J2ME Polish project compiled okay (using javac and Ant) I figured it must be something antenna-specific. So like any good troubleshooter at a loss for leads, I googled the error message. Perhaps googling this same error message led you here. 😉 If so, you’re in luck because I tracked it down.

Google yielded a page that mentioned that this error appears when you use Ant’s Javac task and set the target without setting the source. I’m still not entirely sure what these version numbers relate to, but I did recall that the Antenna home page mentioned that the Antenna WtkBuild task extends the Javac task and sets the target to 1.1. In fact, if you look in the source code that you’ve downloaded from Antenna, it’s pretty easy to find the line where it does it. It looks like this: setTarget(“1.1”);

Now, you can add a call to setSource in the code and then rebuild and rejar the Antenna code, but — as you might guess — you can also just set this value in the build.xml file in the command where you call the “wtkbuild” task. I’m not sure what the optimal values for source and target are in this case, but through a little trial and error I found some that worked:

<wtkbuild srcdir=”${midlet.home}/src” destdir=”classes” preverify=”false” source=”1.3″ target=”1.1″/>


<wtkbuild srcdir=”${midlet.home}/src” destdir=”classes” preverify=”false” source=”1.5″ target=”1.5″/>

Some other values I tested yielded other amusing error messages such as the following:

[wtkbuild] javac: invalid source release: 1.1

For my next adventure I will write my own Ant task!!! Stay tuned!!! 😀

One more time, from the top!!!

My task for today was to set up my home development environment from scratch.

Obviously this should be nothing for a serious programmer, but the problem is that my Sys Admin is just too nice!!! So I’ve been spoiled — for many tasks I could do for myself, I had a bad habit of saying “Oh, I’ll just ask my Sys Admin to do it.” This includes browsing around the site to find the right Java SE and Java ME versions to download and install. This is weirdly more confusing than it should be, made worse by the fact that I left my java developer account username and password on my computer at work only, and when I hit “send” on the “forgot your password” page, of course it sent the password to my work email address, which I can’t access here. D’oh! So I had to make another account…

I had to get Java SE installed in order to install the wireless toolkit to develop for Java ME, and annoyingly since our last Linux upgrade, the version of Java SE I’d been using seems to have disappeared — I could only find pre-1.4 versions of the JDK, which aren’t recent enough. But with a little navigation effort, I managed to find myself a JDK 1.5.0-09 and a WTK 2.2 download for my system. The installation was simple enough that I won’t bore you with the details. Just read the “read me” — if you can find it on their site!!! Mwa-ha-ha!!!

Once everything was installed, I launched KToolbar. Writing my book, I’d gotten into the habit of running from the command line, keeping in mind that the documentation will tell me all of the possible environment and preferences options. But there’s also something to be said for having a nice GUI where all of the possibilities are right there in the menus. I would recommend being familiar with both the “for simplicity” (GUI) method and the place to go to look deeper. As I’ve said, the WTK documentation is pretty good, and you can find most of the things you’d like to do there.

So from KToolbar, I selected “create a project” for my “Jump” (Tumbleweed) game, and — as expected — the program created everything I needed exept the source code. 😉

Then I copied all of the source files from my Jump game into the directory that the “create a project” option created. I’ve zipped it into a nice file, so if you have your WTK installed, just unzip this under the WTK’s apps directory, and the Jump project will be there when you choose “open a project.” Then build (under the “project” menu) and run.

Now, exactly as Seapegasus discovered here, you’ll find that the screen is too big, so — since I’ve carefully optimized this game for a particular screen size 😉 — you get an exception.

I could go to the source code of and change the screen size requirements, but it looks like Seapegasus has proposed an interesting exercise where that would be cheating. 😉

How do we change the screen size to emulate (and write a program for) the screen of a smaller device? It’s really not obvious… Wandering through KToolbar’s menus, there are a lot of items you can tweak, but screen size isn’t one of them.

Since I wrote this program, I feel responsible for making the effort to figure out how to get it to run. And it’s a fun opening exercise to get to know the entrails of the WTK’s file-structure. 😉

My first instinct was to go after some familiar configuration files that I have to modify all the time in my daily life: WTK/lib/internal.config, WTK/lib/system.config, and WTK/wtklib/ Just look at them — you’ll see that you can modify a lot of system parameters directly right there, especially dealing with networking and communications. But none of them said anything about screen size…

So digging around some more, I noticed the WTK/wtklib/devices directory had subdirectories for all of the various devices…

So, I made a copy of the whole directory “DefaultColorPhone” naming it “CarolColorPhone” ;-), and renamed the under it to In that file I found “screenPaintableRegion.width” and “screenPaintableRegion.height” and thought “Aha, jackpot!” Looking at the values in, I saw that all I needed to do was change the value of “screenPaintableRegion.height” to 250.

Then I ran KToolbar, and “CarolColofPhone” appeared in the little “Device” drop-down menu, and had the desired screen size. This was a particularly fun exercise, because I did the first thing I guessed to do and it worked!!!  (Well, almost the first thing…)  That usually doesn’t happen — it always seems like in an unfamiliar system it’s a little tweak here and a little tweak there for hours until you zero in on what you need to do.

Of course as always, eliminating one bug makes it run just up to the next bug…

The next thing I got was a…

This is a familiar enough exception with a new set-up that I should have guessed off the top of my head what the problem was, but I didn’t. So I added an “e.printStackTrace()” in a strategic location and built and ran again. Can you guess what it was? If not, the stack trace should make it pretty obvious!!!
    at javax.microedition.lcdui.ImmutableImage.getImageFromStream(+15)
    at javax.microedition.lcdui.ImmutableImage.<init>(+20)
    at javax.microedition.lcdui.Image.createImage(+8)
    at net.frog_parrot.jump.Cowboy.<init>(+6)
    at net.frog_parrot.jump.JumpManager.<init>(+72)
    at net.frog_parrot.jump.JumpCanvas.<init>(+249)
    at net.frog_parrot.jump.Jump.<init>(+75)
    at java.lang.Class.runCustomCode(+0)
    at com.sun.midp.midlet.MIDletState.createMIDlet(+19)

Oops, forgot to copy the image files into the right place where they’ll be included in the game’s jar file!!! D’oh!!

But easy to fix. And now it runs, yay!!!! 😀