The first book in Apress’s Blackberry series appeared this past November: Beginning BlackBerry Development by Anthony Rizk. Naturally I picked up a copy because I was curious to see how his approach (and his book) compared to my upcoming book (Learn BlackBerry Games Development, written in cooperation with Andrew Davison). Fortunately, the two books cover quite different subject matter. I’d even say they’re complimentary. It turns out that there’s quite a lot to say about the BlackBerry platform because the application lifecycle/behavior/philosophy is very different from MIDP (even though you can run MIDlets on it), plus BlackBerry has a dedicated server-side network that you can program for. John M. Wargo — who reviewed Rizk’s book on Planet Lotus — says that his book on BlackBerry Development Fundamentals is also complementary with Rizk’s. (It kind of makes me wonder if there’s overlap between my book and John Wargo’s — but I doubt there’s much.)
Rizk’s book — being an intro book — doesn’t assume a high level of Java/programming knowledge. In Chapter 1, he warns the reader that “This book is not an introduction to object-oriented programming, or even to the Java language.” However, if you’ve taken one course in Java programming or have worked through an intro book on the subject, “Beginning BlackBerry Development” would be a fine next step. It covers all of the fundamentals of how to build and deploy a BlackBerry Java application, how the application lifecycle works, how to build a user-interface (and respond to user input), the differences among the four or more different types of data persistence on BlackBerry (and how to use them), the different types of BlackBerry network communications available, and how to program for the GPS.
They timed the book to come out in time for the holidays (as well as for a BlackBerry dev conference), and it’s true that the book would make a good gift for a technophile in your life who’s thinking of going into software engineering or for a software engineer in your life who has a BlackBerry and is thinking of maybe trying to sell an application on BlackBerry App World. (And if they like it — and want to take it to the next level with the techniques for making games on the BlackBerry — well, you can guess which book I’d recommend they try next. 😉 )
I downloaded and installed Inkscape in order to draw an animation to play with the Scalable Vector Graphics API. Inkscape was quite helpful for creating my game’s opening SVG animation (though it would have been more helpful if it could save the file in “SVG Tiny”…). What I didn’t expect was how helpful Inkscape is for drawing standard game sprites — drawn first in Scalable Vector Graphics format, then exported as PNG files!
I needed an rocket sprite for my “Space Explorer” game. Here’s what I came up with:
You can see that the four frames give a spinning effect. (The lower row gives the frame sequence for when the engines are turned on.) I’m more an engineer than an artist, but here’s how Inkscape and SVG made it easy for me to draw this: Read more »
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):
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!
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:
- 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.)
- 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.
- 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…
- How do you simulate the SMS to test the application launch with the PushRegistry? I explained that here.
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: Read more »
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: Read more »
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.
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! Read more »