Developing Applications for the RIM BlackBerry

by P.V. Subramanian

One would have thought that the laptop-toting, VPN-tunneling executives of today had little time left to give. The cell phone occupies them in their cars, and even the lengthiest flights become working sessions, thanks to spare batteries and more DC connections in business class.

If a few moments remain -- say, during dinners, movies or meetings -- wireless pagers can exploit them. The BlackBerry pager from Research in Motion (RIM) is one of the best known; so small you could hide it under your napkin, yet so talented that it can suck your email out of thin air. In short, a hip gadget for two-timing execs, trying to do two things at the same time, like responding to emails in meetings.

Other pagers can do email too; send, receive and compose. So what is the BlackBerry's unique selling proposition? RIM markets it on the basis that you don't need a desktop InBox and a separate RIM InBox. Combine the BlackBerry with some MS Exchange and Lotus Notes-based software-call it the BlackBerry Enterprise Solution--and your corporate InBox rips through firewalls to appear on your handheld. And thanks to the same enterprise software, no one can tell the difference between emails sent from your RIM and those sent from your desktop.

But I think the great thing about it is that the BlackBerry handheld is a fully-programmable handheld computer, built around a 32-bit Intel 386 processor, the same kind that could once run Windows.

In this introductory article, I'll cover basic details on the BlackBerry's hardware, operating system, and software developer kit (SDK). Then I'll cover some of the low-level wireless stuff, to familiarize you with its communication technology. Finally, I'll show you a sample application for RIM, a simple Hangman game.

Figure 1. More than just messaging devices, the RIM 950 and the Palm-sized 957 (shown above) are fully programmable handheld computers. This article shows how to program a simple Hangman game for the devices.

The Hardware, the Operating System, and the SDK

The preferred platform of choice today for developing RIM applications is Visual C++ (version 5.0 or greater). However, ever since RIM announced the "early access" Java development environment last year -- based on Sun's KVM -- there has been eager interest in a version that's fully J2ME compliant. RIM recently announced that it would begin shipping its first J2ME-compliant model later this summer.

While the single InBox story makes for a great sales pitch, I think the common tinkerer got handed something much more exciting: a tiny PC with built-in, always-on wireless connectivity that one can easily write applications for, single InBoxes just being one of them. Think point-of-sale systems, self-monitoring gas meters, remote control for your entire home, and you'll be getting the drift. (Other wireless devices are getting to the corporate InBox as well -- OS CorporateLink from OmniSky is one example -- so the InBox pitch may not work much longer for RIM.)

Blackberries come in two basic flavors, the pager-sized model with up to eight lines of display, and the palm-sized model with 19. In that tiny space lies confined a multitasking, multithreaded operating system, capable of running 31 applications at the same time. Applications are expected to be well-behaved, yielding control every so often, but in this dog-eat-dog world that's not quite enough. So the RIM OS has a couple of watch puppies triggering resets on encountering CPU hogs and deadlocks.

Memory. Writing applications for the BlackBerry requires coming to terms with the very small amount of memory available to your applications; 4 or 5 MB of flash memory and 512 KB of SRAM is all you have. Flash memory is the "disk space" available for your applications, but unlike a regular disk, read, write, and modify operations are dramatically different in terms of access times. Flash memory can be written in small increments, but erasures need to be performed on entire 64-KB sectors. So modifying even a single byte involves erasing an entire sector, and rewriting it with the modification. To counter this problem, the RIM OS simply chooses not to modify existing sectors at all, writing these modifications as sectors of new data instead, with the old data marked as old data. Old sectors are deleted when the file system runs out of space. Applications rarely seem to access the raw file system though. Unlike conventional applications, all file access is through a database API. For RIM applications, files are databases, and file contents are made of variable-sized database records.

Comment on this articleWhat do you want your RIM to do for you? And if you are developing exciting RIM applications, tell us about it.
Post your comments

User interface. One very un-pager-like feature of the pager-sized BlackBerry is its no-compromises user interface. As a developer, it is for you to decide how much to enrich your application's UI with widgets, but you have a surprisingly large menu to choose from: graphic icons, custom fonts, dialog boxes, edit boxes, and lists. User interaction is generally through the use of the clickable thumbwheel, much like the wheels on mice. The keyboard is so small, one would venture to suggest that the best BlackBerry applications use as little of it as possible.

Audio support in the Blackberry is about what you would expect from a PC speaker. You have simple control over frequency, intensity, and duration that lets you create a few tunes. Someone might make an MP3 player of it yet, but there is no really good reason to try it.

RIM's Wireless Protocols

At the core of the BlackBerry is its ability to send messages wirelessly. The Messaging API is what you would use for such high-level use of the communications stack, like sending emails (with MIME attachments and all), fax and phone. (Yes, phone! Skytel has a RIM-based service where you can send a message to a phone and a machine reads it out to the intrigued recipient.) RIM's SDK also includes a Radio API for packet-level access to the radio network, but it's unlikely you'd ever need to get down to the bits for your average power-executive application. But if you are going to be using the radio API, a good understanding of the prevalent protocols is useful.

Wireless handhelds cannot simply throw their data into the ether and hope for it to be picked up by a carrier. Not unless these packets conform to whatever standards the carrier's network is expecting. RIM's handhelds come in the Mobitex and DataTAC flavors. In the USA, Motient operates on DataTAC and BellSouth does Mobitex. (The Palm VII operates on Mobitex as well.)

Both Mobitex and DataTAC are packet-switched protocols. All connections between the wireless unit and the base station are session-less and shared. Data delivery is guaranteed, but since the network uses a store-and-forward mechanism, delivery times can vary significantly.

DataTAC is a narrowband PCS network, available around the world. DataTAC communications are broken up into SDUs, or Service Data Units. SDUs are addressed to other DataTAC equipment in the network by the use of Logical Link Identifiers (LLIs), which uniquely identify fixed or mobile DataTAC terminals (like BlackBerries). A single SDU can have up to 2,048 bytes of routing and payload information. Of course, all of this data is never transmitted in a single huge burst. SDUs are further broken up into smaller packets by the radio (usually 512 bytes). Each SDU is then transmitted at 9,600 bps or 19,200 bps. (You'll see that it is extremely difficult to answer the question "How fast is the data transmission?")

Mobitex communications are centered on the MPAK, or the Mobitex data packet. Packets are addressed through the use of 24-bit Mobile Access Numbers (MAN), which uniquely identify Mobitex-compatible equipment and are assigned by the manufacturer -- if you have a BlackBerry from BellSouth, look inside your battery compartment. After all the address and header information is put in, an MPAK can take 512 bytes of payload data.

Costs of Entry

In beginning to write applications for RIM devices, one of the biggest obstacles is the cost of buying these babies. BlackBerries are definitely expensive. The pager-sized unit typically costs about $400, activation takes another $30, and service can cost anywhere between $10 and $60 a month.

The Palm-sized units cost about $100 more, while activation and service costs are unchanged. In comparison, a Minstrel wireless modem for your Palm costs the same in service charges, and the modem could be free with a year-long contract. But the excellent simulator that comes with the SDK should leave developers with no excuses for not trying. Apart from a look-and-feel that mimics the BlackBerry precisely, the simulator also lets you treat your PC's serial port as a wireless modem. So with two PCs hooked up over a serial link, and running RIM simulators, you should have a very good "wireless" network to test your applications in.

If you are a little more adventurous, RIM also OEMs its equipment as a processor-radio combo. You get an Intel 386, a meg-and-a-quarter of memory, and the same OS as the off-the-shelf handhelds. The OEM units have numerous interfaces and so forth, and a couple of these interfaces are similar to RS-232.

As with the handhelds, there are Mobitex and DataTAC versions of the OEM equipment. And as with the handhelds, I found the OEM kit pricing, at $1,000, a bit steep. But then there are the millions awaiting you once you have wireless Tetris written for the BlackBerry. Or the less-challenging Hangman, which we shall presently set about building.

Pages: 1, 2

Next Pagearrow