April 24, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

The 10 Biggest Mistakes Developers Make with QUALCOMM BREW, Page 2

  • March 2, 2006
  • By Ray Rischpater
  • Send Email »
  • More Articles »

5. Doing Too Much Computation Within a Function

With today's faster processors and BREW 3.1, this is less of a problem, but I remain impressed by the number of engineers I've met who neglect to remember that QUALCOMM BREW is a cooperative multitasking environment running on a relatively lightweight computing platform. Expensive computations of any sort are best broken up into small pieces and run in an asynchronous manner using ISHELL_Resume or through the application's event handler. If you're used to writing multithreaded applications on other platforms, this can be somewhat of a chore, but if you're an old hand from the early days of the Macintosh, Newton, or Palm Powered platforms, this is often easier than relying on multithreading. Regardless of today's hardware capabilities, if you aren't careful, you can easily construct functions that block the processor for too long. To prevent a handset from locking up permanently—an important feature for a device with no reset button that may be needed at any moment in an emergency—the underlying operating system has a watchdog timer. If your application blocks the processor for too long, the watchdog timer will fire and reboot the handset, terminating your application. This looks suspiciously like any other crash, and can be very challenging to find, especially if it only occurs in some circumstances (say when sorting an extremely large data set).

4. Confusing FREE() and Release() Calls on Memory and Objects

This one amazes me—not because it happens, but because it still happens, to experienced BREW developers. (In fact, I caught myself making exactly this mistake recently, after I'd already written a preliminary draft of this article!) The problem is simple and about as subtle as a bull in a china shop: if you attempt to invoke FREE() on an interface, at best you'll leak the underlying resources used by the interface, and you'll frequently corrupt the heap as well, causing a random crash a little while after your erroneous FREE(). In a similar vein, by invoking a Release() method on a heap region, you will witness an immediate crash as BREW attempts to dereference into the (nonexistent) virtual table of the heap region looking for the Release() method. Unfortunately, the heavy dependence on void pointers when writing BREW applications in C makes this mistake very easy, because many BREW applications frequently sidestep strong type checking by the compiler. Worse, many organizations wrap the BREW memory and interface allocation and deallocation interfaces with procedures to permit better tracking of memory leaks and the like, making it harder for developers to spot the rather obvious incongruity of seeing ISHELL_CreateInstance() at the beginning of a function, and FREE() at the end of the function on the freshly created object.

3. Insufficient Testing of Poor Network Coverage for Networked Applications

It's very difficult to accurately simulate all that can go wrong on a wireless network using the BREW Simulator. Simply pulling the network cable (or turning off the office WiFi access point) won't do it because the cellular network is a significantly more complex beast than today's Ethernet networks. Worse, some kinds of network activity, such as voice calls or SMS, can't be fully simulated at all on your development workstation. Fortunately, there's an easy way to test marginal or no network coverage: buy a metal cookie tin or empty paint can. When sealed—so there are no cracks between tin and lid—either makes an excellent Faraday cage, which blocks all radio energy to anything inside the cage. By putting the handset under test in the container and closing the lid, you can simulate an out-of-network condition without needing to visit your local fallout shelter or cave. Where I work, nearly everyone has a cookie tin left over from a previous holiday binge (or a paint can from the local hardware store), and simulating poor network coverage is a standard procedure for both software developers and software testers.

2. Insufficient Testing of Suspend and Resume Cases

QUALCOMM BREW is a cooperative platform: You run in the same task as other BREW applications, and must share memory and CPU resources accordingly. One of the ways this is enforced is through the suspend/resume contract you must uphold with the system, in which your application should release as many resources as possible when it receives EVT_SUSPEND, and restore those resources when it receives EVT_RESUME. Unfortunately, although an increasing number of developers are getting very good at implementing suspend and resume cases, returning as much as of the handset's resources back to the system as possible, it's an area that's seldom well-tested until you submit your application to NSTL for True BREW Certification. To avoid this, ensure that you include suspend/resume testing in your test plan early, and test these cases often throughout the development life cycle. Fortunately, this testing is simple—simply send the handset under test an SMS message or phone call while your application is running. Of course, it's best to do this several times, with your application in different states. As you do so, ensure that the application resumes correctly, restoring the display, audio, and any entered information as if the application had never been suspended.

1. Insufficient Testing on the Target Handsets

Probably the most common and the most dangerous mistake you can make when developing for QUALCOMM BREW is to rely too heavily on the BREW Simulator for application testing and performance profiling. Although the BREW Simulator is an excellent tool, it simply can't compare to on-device testing, because it differs from the handset in many ways, including:

  • Processor architecture. BREW-enabled handsets are based on integrated circuits utilizing an ARM core, not the Intel Pentium architecture used by the development platform. The simulator executes your application as a Windows DLL compiled for the Pentium processor, not as an emulator of the ARM processor.
  • Media codec support. The BREW Simulator appears to leverage Microsoft Windows Media codecs for many media types, meaning that what works in the simulator when it comes to multimedia may not work on a handset. Moreover, some handsets have defects in their multimedia implementation through the IMedia interface and its subclasses, meaning that you can't simply test in simulation and be sure that it works.
  • TCP/IP support. The BREW Simulator has a number of features that let you simulate things such as network performance as though you were running over the cellular network. Unfortunately, the BREW Simulator uses the same TCP/IP implementation as the rest of Microsoft Windows, not the TCP/IP stack or physical transport used by a handset, and behavior between the two can vary greatly.

If you've made one or more of these mistakes, join the club—you're not alone! Hopefully, reviewing this list of mistakes will help you avoid them, and perhaps remind you of a few of your own that you may make from time to time.

Related Resources


About the Author

Ray Rischpater is the chief architect at Rocket Mobile, Inc., specializing in the design and development of messaging and information access applications for today's wireless devices. He is the author of several books on software development, including eBay Application Development and Software Development for the QUALCOMM BREW Platform, both available from Apress, and is an active Amateur Radio operator. Contact Ray at kf6gpe@lothlorien.com.

Page 2 of 2

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Sitemap | Contact Us

Rocket Fuel