The BlackBerry Red Key!

When I’m running an application on a BlackBerry device — and I hit the red key — my app disappears, and the menu screen reappears. I’d guess that my app’s screen was popped off the BlackBerry screen stack, so onClose() was called and my app cleaned itself up neatly, right?

Wrong.  The application was merely sent to the background.

I assume this behavior is mentioned somewhere in the bowels of the RIM documentation (although I’ve read quite a lot of it, and I haven’t seen mention of this). Nor do the sample applications appear to deal with it. I just figured it out when my colleague Andrew Davison sent me a game that plays music in the background. It was a tad loud, so I instinctively tried to shut it off in one click using the red key. And the game went away, but the music kept right on playing…

It reminds me of a little something I read in the PodTrapper story:

My curve has 32MB of RAM and 64MB of flash. The flash can be used for paging if it’s available, but on my device only about 20MB of it is, and that fills up fast installing applications (PodTrapper alone is 350k). Realizing that the OS and other apps also have to fit in RAM, leaking a 100kb string becomes a huge problem. There are lots of forum posts by people trying to figure out why their phone keeps running out of memory and needs to be rebooted. It’s a large enough problem that there are apps for automatically restarting your phone. I can definitely see why Apple has been hesitant to open up background processing on the iPhone. It’s really easy for bad developers to make the whole platform look bad.

Personally, I think it’s kind of cool that you can run apps in the background on BlackBerry, and send them to the foreground and back. However, I think the simplest, default behavior should lean towards cleaning up the app neatly, while sitting on memory and processes when your app goes out of scope should be a special behavior that advanced developers can request.  Not the other way around.

So what about that red key?  What if you’re developing a game or animation that makes no sense in the background, and you just want it to clean up whenever the user dismisses it?

Andrew proposed the following solution (for use in a subclass of Screen):

Freelance BlackBerry Developer Needed

I’m looking for one engineer (who has worked with BlackBerry) for a fun little project. It’s a paid project, not just a hobbyist idea.

If you’re interested, please leave a comment, and I’ll email you.  Thanks!

Trying out BlackBerry App World

For fun, I’ve submitted one of my sample games (Ladybug Maze) to BlackBerry App World.  This is mostly an experiment to try out how BlackBerry App World works — I doubt many people will pay $2.99 for this simple little game. But who knows?

BlackBerry PushRegistry How-To

Suppose you’d like to create a BlackBerry application that will launch when you send an SMS message to the appropriate port.  It’s possible, but there are a number of non-obvious (and not-necessarily-documented) tricks.  I spent a few too many hours on experimenting to figure out precisely what works, and I’m posting my notes here to save you some time:

1. Apparently your application has to be a MIDlet, not a “CLDC application” (RIMlet).  I was a little surprised when I read this in the BlackBerry Java Dev forum, since it would undoubtedly be trivial for RIM to allow either type of application to register with the PushRegistry and get launched.  So I did a few tests (with a “MIDlet-Push-1″ Jad property analogous to the way the RIMlet uses the “MIDlet-1″ property), and, indeed, the PushRegistry doesn’t seem to work for RIMlets, but it works fine for MIDlets. (Note: it’s still theoretically possible that there’s a way to make it work for RIMlets, but I couldn’t find the trick.)
2. Adding a custom property to your Jad file is really easy if you know the trick. The trick is that (in the BlackBerry JDE) you can add the Jad file to the project (in the same way you add source files and images).  Once you’ve added the Jad file to the project, you can add properties and then they won’t get overwritten when you rebuild.  But before you add it, you should modify the project properties (setting the application type to MIDlet) and then build the project once, so that it will create for you a correct initial Jad file to use.
3. Before your application closes, you should dynamically re-register with the PushRegistry.  This was the trickiest one to guess!  If your MIDlet is launched by the PushRegistry — and you open the corresponding connection to read the SMS message that launched your MIDlet — this automatically unregisters your MIDlet from the PushRegistry.  With other handsets, once you’re registered with the PushRegistry (either statically in the Jad or dynamically from within the application), you stay that way until you actively unregister it.  But not BlackBerry.  Or at least not with the BlackBerry simulator that comes with the BlackBerry JDE 4.2.0.  I assume the behavior is the same in other versions and on the device, but I’m not certain…
4. How do you simulate the SMS to test the application launch with the PushRegistry?  I explained that here.

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 SmsDemo.java (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:

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: 

Carol Hamer, PhD, CTFL

I just received my official certificate in the mail from the American Software Testing Qualifications Board certifying that I’m now a Certified Tester, Foundation Level. The funny part is in the letter where it says that I’m now entitled to put the letters “CTFL” after my name on my business cards and letterhead. No offense to the ASTQB (and ISTQB) folks, but the test is really easy, so I’m not sure how impressive it will look (especially following the old “Piled Higher and Deeper”).

That said, I felt the ISTQB course was fun and worthwhile. I was working for a QA consulting company in Switzerland, and instead of taking a formal course, the employees organized an informal study group. One colleague divided the syllabus into lessons, and then we met once per week to discuss that week’s assignment. Most of the concepts in the Foundation Level syllabus are the type of things that are simple (once you read them) but you might not have thought of spontaneously. So it’s interesting to get together among colleagues and discuss. For someone like me (who has primarily seen QA from the outside, while working in development), it’s useful to take the time to understand QA from the high level concepts to the practical techniques.

I didn’t take the test with the rest of my “class” because I left Switzerland before we were done. But since the ISTQB is an international board, it was simple to just take the test after arriving in the U.S.

A range of ideas and perspectives: iPhone Games Projects

Even though I’m still playing with MIDP for the moment, it’s fun (and instructive!) to look over the shoulder of some of the people developing games for other device platforms.  I’ve done a little bit of work on the Android platform, and naturally I’d like to know what’s up with the iPhone as well.

So I picked up a copy of iPhone Games Projects by PJ Cabrera (and others).  This book is unusual for a computer book in that they gathered up ten highly successful iPhone game developers to give their best secrets and advice, so it gives higher-level project strategy ideas instead of spelling out all of the technical nitty-gritty.

Overall, the book answers the following questions:

• What makes an iPhone game great?
• How do you plan and execute a successful professional iPhone project?
• How do you optimize for the iPhone?

The authors all present different perspectives on the subject, which naturally invites the reader to contrast them and think about their ideas!

Hello BlackBerry!

It’s been my experience that all MIDP implementations are different, but some are more different than others.  BlackBerry Java smartphones are MIDP compliant, but they have a particularly unique flavor of MIDP.  They’re also becoming increasingly popular, so I decided it was time to get one and try it out.  Here’s my new (to me, actually used) BlackBerry 8700g:

By selecting “options > about” I got the convenient info screen above, which tells me that the version is 4.1 — one of the oldest BlackBerry handsets with Java.  (That’s OK, all the better to test backwards compatibility.)

The first (and IMHO most annoying, but critical) step is to set up the development environment and get a complete “Hello World!” from code on the PC built and running on the device.  Here’s my “road to Hello World” — the problems I encountered and their solutions — in hopes of saving the next person some time:

Do-it-yourself custom GUI for a range of MIDP devices

Suppose you’re writing a game or application, and you’d like it to have an attractive, professional-looking GUI (with your theme, brand, or skin), and you’d like it to run on as many Java ME MIDP devices as possible.  There’s some work to be done, but it’s not that hard.  I wrote about how to do it in the last chapter of my book, and it was the topic of my Jazoon talk.  Plus I wrote a library of utilities to simplify the task (the Frog-Parrot UI Library), but — looking over my blog the other day — it hit me that I never really posted a technical explanation of how to use this library.

Here’s the general idea:

If you want a mature product for MIDP customization — one that will teach you how MIDP customization works as you’re using it — J2ME Polish is a good place to start, as I explained here.  But in practice, I found that I wanted 100% control over the look-and-feel of the GUI, which I couldn’t get from J2ME Polish.

Essentially, handsets have a list of standard screen sizes, and many of them are so small that I need to have pixel-by-pixel control over where everything is placed.  Having the device place the widgets, etc., for you — guessing where you want them based on layout algorithms — isn’t nearly as useful on a small screen as it is on, say, a big browser window on a P.C.  So I wrote a library that would allow me to bundle the screen information into resource files, selecting the right image files for each screen size and passing along the data for how big widgets and images are and where they should be placed.

The annoying thing about making a custom GUI for MIDP is that you have to start from scratch, drawing your GUI onto a blank canvas.  That means re-inventing the wheel on some very standard functionality: widget navigation, navigating back and forth through a stack of screens, scrolling, and even cutting up a paragraph of text in the right places so it won’t disappear off the edge of the page.  That’s the functionality I’ve written for you in the FPUIL (which you can use however you like, as long as you don’t imagine it comes with a warranty. ).

In this brand-new version (which I just re-worked today on a Windows machine, download here), I’ve included some build files to build the project with Ant and Antenna. Look at the build.xml and build_all.xml files to see some examples and explanation of how to build a MIDlet for different target devices.

That should be enough to get started, and if I find some time, I’ll try to write more explanation…