Archive for the ‘BlackBerry’ Category
As I said the other day, I started my space explorer game by trying out a bunch of different ways to animate the rocketship flying through space. (I’ve bundled all the source code and resources for the complete example — you can download it here.) I started by just creating a standard MIDlet using the javax.microedition.lcdui.game classes. Here’s what it looks like in the debugger:
In the image, I’ve set the debugger to show memory usage. In this case it’s “lcduispace” — the top process on the list. Next, I decided to try out the technique I described in my earlier post: use the same lcdui game implementation, but write each frame into an image buffer and transfer it from the MIDP Graphics implementation to RIM’s proprietary implementation to display it in a RIMlet. Here it is in the debugger: Continue reading
When I first started programming for BlackBerry, one of the things that struck me as most odd was the two completely independent graphics APIs. For MIDlets, there’s javax.microedition.lcdui.Graphics, and for RIM’s own profile, there’s net.rim.device.api.ui.Graphics. The two versions are so similar to one another that — if you’re careful — you can write a game that can use either of the two graphics APIs interchangeably, just by swapping out the include statements (and using a different set of lifecycle classes). That’s what I illustrated in Chapter 3 of my book.
But I wondered: What if I want to use the javax.microedition.lcdui.game package? But I still want to take advantage of RIM’s proprietary UI component handling? Is that even possible? Note that you can’t just place an LCDUI Sprite onto a RIM Screen or use lcdui Images interchangeably with RIM Images. Yet, there’s nothing to stop you from instantiating many of the lcdui graphics-related classes in a RIMlet — either type of application has access to the whole API.
Through experimentation, I found that it’s quite possible to take a game that was written using lcdui game Layers and run it in a RIMlet. The trick is the following: Continue reading
So, my new book — written with co-author Andrew Davison — is done and ready to go!
Have a look at the book’s website to get an idea of what you’ll see:
- Chapter 1. Gaming on BlackBerry!
- Chapter 2. BlackBerry Application Basics
Why are there two types of BlackBerry Java applications? What are all those crazy files the compiler generated? And – most importantly – how do I get an application complied and running on my BlackBerry smartphone? Chapter 2 will answer all of these questions, plus help you set up a professional build with Ant.
- Chapter 3. Game Graphics and Events with MIDP and RIM Classes
Using the classic Maze game as an example, you’ll see exactly how the two types of BlackBerry Java applications differ. You get an in-depth look at how the lifecycle, events, and graphics work in both cases so you’ll be ready to develop whichever kind is best suited to your game’s needs.
- Chapter 4. Adding a Professional Look and Feel
Gorgeous graphics are critical for the game experience. To get your game’s visual theme pixel-perfect on every model, BlackBerry gives you the tools, and Chapter 4 explains how to use them.
- Chapter 5. Security and Selling Your Game
As much as you love games for their own sake, at the end of the day it’s nice to get paid. In Chapter 5 you’ll see how to sell your game on BlackBerry App World (or on your own site) – plus how to apply the cryptography APIs to implement licensing and Digital Rights Management.
- Chapter 6. Swingin’ Light Saber
With action, music, sound-effects, colliding game sprites, and even touch-screen input, Andrew shows you how to put it all together and develop a real game. Plus BlackBerry’s accelerometer lets you wield your saber like a true RIM-i Knight!
- Chapter 7. Play a Live Opponent with SMS
That classic, tiny packet of data sent by the Short Message Service is still a favorite with users and operators alike. And it’s all you need to play a trans-atlantic game of Checkers with a friend – chosen from your BlackBerry contact list!
- Chapter 8. Using Scalable Vector Graphics
2-D graphics are easy to master and allow you to create surprisingly impressive effects. Check out Chapter 8’s spinning spaceship video and learn the tricks to create it.
- Chapter 9. Creating Role-Playing Games on the Internet
Since Internet everywhere is BlackBerry’s strong point, it was practically born for Massively Multiplayer Online Role-Playing Games (MMORPGs)! Chapter 9 uses Twitter to create a virtual asteroid belt that you can explore and find real people in their own virtual ships.
- Chapter 10. Remotely Drive a (toy) Sports Car
What’s more fun than driving a remote controlled car? Driving one from your BlackBerry! Andrew illustrates Bluetooth programming in style.
- Chapter 11. Fox and Hounds
Here’s something your stationary game console can’t do: a real live game of hot pursuit – based on GPS!
- Chapter 12. Introducing 3D with JSR 239
Have a look at what the latest-and-greatest version 5 BlackBerry smartphones can do! Andrew explains 3-D graphics with OpenGL.
Also note: I have some “outtakes” — sample games and code that didn’t quite make it to the book but are nonetheless kind of interesting. I’ll be posting them here over the next few months.
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. 😉 )
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: Continue reading