Technical Articles & Books

E-mail on the Phone: Writing Great Software

Writing and selling e-mail programs for cell phones may not be easy, but this huge market has this big advantage: It's not overcrowded yet. Oh, and BREW makes the selling part a lot easier. Andrew Binstock provides a handy overview.
by Andrew Binstock

For years, the idea of getting e-mail access on a handheld device has held considerable allure for many users-yet sales of such devices haven't measured up to the promise. Consider, for example, the RIM Blackberry devices. Despite their cachet, the cost of the hardware and the mail service's high monthly fee have relegated them to only 615,000 subscribers as of June 2003, according to CS First Boston research. With such a small installed base, few applications have been developed for Blackberry devices.

Today, e-mail access on handheld devices is appearing in a new, much more economical form-on cellular phones, which with their increased functionality and low prices are becoming ubiquitous. Developers rightly see a significant opportunity to write software for this large, still-untapped market.

Not that it's easy writing for these devices. Constrained RAM, screens, and processing power are challenges to the programming arts, weaned as they have been in recent years on the limitless horizons of the PC. The many variations in platform hardware, system software, and screen dimensions make one nostalgic for the monotone horizons of the PC space. New tools must be mastered. And for those intending to sell their software creations, the cost and headaches associated with marketing, selling, and collecting revenues from one's software efforts introduce a whole new level of torture to the equation.

Into this problem space step the hardware and software platform vendors, hoping to make the development process easier so lots more software will show up quickly enough to feed the hungry hundred-million customers while their enthusiasm is high. One such platform for writing these applications is BREW, a well regarded set of tools, platform, quality control system, and distribution system developed by Qualcomm for cell phones using its CDMA technology.

One early and important question that should be in your mind is: How big is the market for BREW-enabled phones? Market research firm, Strategy Analytics, estimates there are 20 million BREW handsets in 2003, with that figure predicted to grow to 60 million by 2004.

Let's take a look at the unique issues programmers face in writing code for cell phones, the programming tools Qualcomm makes available to developers, and how the BREW delivery system helps developers market their software and collect revenue from the users.

What does it take to write software for cell phones?
If you're familiar with C/C++ or Java, then you have the language skills you need to write cell phone apps. The specific tools you need are easy to come by. In fact, Qualcomm's BREW platform and software development kit are freely downloadable. This toolkit comes with a Windows-based emulator for a BREW phone and development tools that plug into Microsoft's Visual Studio. The SDK also includes considerable documentation.

BREW supports C/C++ natively, and J2ME via a small runtime add-on. Development is generally performed in Visual Studio and code is tested on the emulator. Code is then compiled for the phone and downloaded to the instrument for testing.

Developing for a cellular phone has several unique challenges, some of which will be familiar to developers who have programmed in the days when resources, such as RAM and processing power, were far more constrained than they are today.

Another important thing to recognize, points out Nicholas Dickey of Codistics, a company that makes QuickMail, a mail-access package for cellular phones, is that when your software is running, "you are in complete control of the device. So you have to check constantly to see if a call is coming in. And if there's a call, you have to relinquish the phone immediately so the user can take the call. Preparing for this means knowing how to save your data and suspend your application on a moment's notice."

Moreover, when you are connected to the e-mail source, you have additional constraints. As Chas Wurster, senior software architect at wireless e-mail client vendor, Tourmaline Networks, points out, "(In contrast) to a PC-based e-mail client, a cell-phone e-mail application must retrieve the user's data as quickly as possible, because the user pays either by the minute or by the byte. The application should download the minimum information required."

Sachin Deshpande from Qualcomm points out that the user interface offers another set of issues that requires careful thought. Not only is precise navigation more difficult with buttons than with a mouse, but you have to remember that the input mechanism-the keyboard-has different constraints. He recalls an e-mail application that required users to log in by entering an eight-letter password, which is a typical design for desktop apps. But on a phone, each letter can require triple tapping a key, which simply takes too long; customers viewed the application as difficult to use. "For authenticating users," says Deshpande, "you ideally want to use numeric PINs, as you do with your ATM password, because each digit is a single keypress."

Designing E-mail Applications for Phones
Anyone who has received e-mails from someone using a Blackberry device has noticed that the message body invariably is amazingly terse. Typing with thumbs forces one to reduce messages down to their essentials. Replace these keyboards with triple tapping a 12-key interface on phones, and you'd expect replies to even shorter.

But bear in mind that e-mail on cellular phones is primarily a reading experience. It lets you discover why someone is late for a lunch appointment, while waiting at the restaurant. Or get confirmation of an event while you're in a cab or on the train. Most e-mail messages in the queue will be ignored based on their subject lines alone. Only the important ones will be selected for reading. The phone screen then presents the text of the message in a scrollable window.

When an answer is necessary, help your customer avoid having to triple-tap every word. Offer standard canned responses by attaching key combinations to full-sentence macros. "Thanks for your help, I appreciate it. Talk to you soon." can be linked to one key, while "Call me on my cell phone. Number follows." can be attached to another. These sentences are followed by a signature file with full contact info. The result is a complete readable message that labors under none of the youthful messaging shortcuts of one-letter words and emoticons. Users can also design their own messages and upload them to their "myWebsite" provided by their cellular carrier, then download them to the phone.

Security, and synching e-mail with the user's other applications must be considered as well. For example, how to redirect the e-mail from MS-Exchange or another email server to the phone is an important question. Should this be done from the user's PC or from another server? Different sites will have different preferences on this point. Fortunately, the BREW platform provides network APIs by which e-mail can be accessed via TCP/IP. As such, it does not impose any special constraints on software development on the server side, nor even require a server side component.

All these questions involve tradeoffs that must be examined carefully. Again, considerable code and practice tips are available on Qualcomm's website

How Do You Market Your Application?
Inspired by the comparative ease of programming for cell phones, you go off and write the grand-daddy of all e-mail clients: full color, sound effects, and terrific ease of use. Great! Now how do you sell it?

Marketing and selling your own wireless e-mail solution yourself is, to put it mildly, an expensive challenge. Fortunately, the BREW program isn't just a set of developer tools for writing programs, but a complete system for getting your apps in front of buyers and getting revenues back in your hands with a minimum of post-sale fuss.

In a nutshell, the process works like this: Developers offer their software to the BREW carriers that they would like to work with. These carriers can then choose to carry the products in their customer catalog. If a user downloads the software, a billing entry appears automatically on his or her monthly statement; and the developer is entitled to 80% of the Developer Application Price (DAP) set by the developer. The entire process is automated from your point of view.

This model has two conspicuous advantages. First, it is well established and successful. It has not fallen prey to the "I want everything for free" mentality that is common in digital media elsewhere. Customers, and especially young customers, expect to pay for software downloaded to their phones.

Second, you can offer your software package on a subscription basis, rather than as one-time purchase, and also offer a limited-time trial. This lets prospective customers try at a lower cost, and for long-term users, it provides developers with an ongoing revenue stream. As long as the software is enabled on the user's phone, monthly fees will be collected.

The process of getting carriers to carry your software involves several steps, all of which BREW helps facilitate. Once the application is developed and tested, you submit the software for TRUE BREW Testing, which is done by an third-party testing company known as National Software Testing Labs. This process verifies that the software works properly on the telephone hardware (and if necessary on the server side) and that it performs no malicious activity. This is critical for assuring the carrier that the various applications won't create support headaches the way they sometimes do on PCs. Says Jay Thrash, a senior developer at InPhonic, a Cary, North Carolina vendor of wireless software, "Qualcomm provides developers with a detailed outline of how the applications will be tested and how they are expected to behave under normal and adverse operating conditions (e.g. low memory, out of network range, and so forth.) Qualcomm also provides a testing toolset to developers to recreate these conditions." Presuming, your software receives TRUE BREW Tested status, carriers are able to include in their product catalogs.

After that, you sit back and watch your bank account grow as payments are collected through the BREW program and deposited directly into your account. Says Karl Schlatzer, vice president of InPhonic, "The BREW program is extraordinary. They make the whole process of selling and collecting for software extremely easy. We were amazed and continue to be extremely pleased by how well this system works."

Andrew Binstock is the principal analyst at Pacific Data Works LLC. Previously he was the director of PriceWaterhouseCoopers's Global Technology Forecasts. His book "Practical Algorithms for Developers" co-written with John Rex is in its 12th printing at Addison-Wesley and in use at more than 30 university computer-science programs.

If you are an authenticated BREW developer or have developed a commercial BREW application and your company name is not listed on the directory, please send us an email.