Before you can start coding, you need a little background.
First, What is BREW?
The BREW SDK is a set of API’s that facilitate the development of softwareapplications targeting wireless handsets. The SDK is free of charge to softwaredevelopers.
For BREW applications to run on a phone, the BREW Application ExecutionEnvironment (AEE) must be present. The AEE is loaded onto phones byparticipating manufacturers, using the BREW Porting Kit.
Some operators require BREW applications to pass TRUE BREW testing beforebeing made available to wireless subscribers. Testing, if required, isconducted by National Software Testing Laboratories (NSTL). More information onthe testing process, including the costs, can be found
The BREW Distribution System (BDS) is a major component of the overall BREWsolution that an operator uses to maintain a market in BREW applications. Itenables subscribers to personalize their handsets by selecting applications anddownloading them, over the air. A billing record is generated for eachtransaction and a corresponding line item appears on the subscriber’s monthlybill. Herein lies BREW’s biggest drawing card for developers — the wirelessoperator and QUALCOMM handle all the distribution, billing and paymentprocessing. The developer receives 80% of the application’s wholesaleprice from QUALCOMM.
The table below outlines BREW’s value proposition. BREW literallyfuels its own success by fostering value and delivering incentive from one endof the business model to the other. For software targeting wirelesshandsets, BREW represents an unprecedented, self-sustaining system. Formore detail, please read the
Party | Employs | Produces | Incentive |
QUALCOMM | BREW Application Catalog, software developers, implementers | All BREW components | – shares 20% of applications’ wholesale price with operator. |
Developer | BREW SDK | BREW Applications | – Market access. – 80% of wholesale price. – shorter time to market due to simple API. |
Device Manufacturer | BREW Porting Kit | Handsets equipped with the BREW AEE | – able to quickly BREW-enable phones to meet operator demand. |
Operator | BREW Distribution System | Marketing capability for BREW applications | – revenue from sale of applications. – increased ARPU from data traffic. – sale of new handsets. |
Wireless Subscriber | BREW Handset (AEE) | Cash | – ability to customize and increase utility derived from phone. |
Why Should I Choose BREW?
Unlike Wireless Application Protocol (WAP), BREW applications execute on theclient. This local processing advantage means BREW applications don’t suffer fromWAP’s network latency issues. For this reason, BREW applications are moreresponsive. Thus, interactive, real time processing and graphic features can beincorporated, as evidenced by several of the games currently available for theBREW platform.
Connected BREW applications can download any required resources when anapplication starts, reducing the need for repeated, network-borne updates asprocessing proceeds. For example, assuming the presence of GPS services, aposition location application can download a map from a web server when it isinitialized, based on the subscriber’s current locale. Subsequently, thedevice’s own processing power can be used to graphically represent the user’slocation as GPS updates are received.
Before BREW, developing software for wireless phones meant an intensive,embedded development project for each targeted handset. BREW provides arelatively high level API that insulates the software developer from thehardware. Thus, porting software to different devices is a relatively simpletask.
This brings us to the question “Is BREW better than J2ME?”. To the extentthat the two platforms overlap, proponents from each camp can put forthconvincing arguments as to why one is better than the other. I’ll leave thosebattles to the so inclined.
In fact, BREW and Java don’t really compete. As Figure 1 shows, the two cancoexist on the same device. Instead of eschewing BREW, Java developers shouldwelcome it since it reduces the likelihood of experiencing Java code portabilityproblems between different handsets. Traditionally, Java requires a different,chipset-specific virtual machine (JVM) for each targeted handset model. Now asingle JVM can target multiple handsets since BREW provides an abstractionlayer over the hardware. In essence, BREW acts as the virtual machine’s virtualmachine. Still, mostly due to devices’ differing screen dimensions, Java onBREW doesn’t quite achieve write once, run anywhere nirvana (neitherdoes Java without BREW). In the mobile handset world, however, that elusiveperfection is closer to reality with BREW in the picture.
Figure 1 BREW & Java![]() |
J2ME virtual machines, targeting BREW and compliant with the Connected,Limited Device Configuration (CLDC) and Mobile Information Device Profile(MIDP), are soon to be released by IBM (WebSphere Micro Environment) andInsignia Solutions (Mobile Foundation for BREW). Both JVM’s require handsetsequipped with version 2.0 of the BREW AEE. IBM is also adding integrated, BREWdevelopment support to WebSphere Studio Device Developer.
BREW’s distribution system (BDS) makes it possible for a JVM (and any othersoftware) to be downloaded and installed “on the fly”, once thesystem has determined that the subscriber has suitable hardware. Subsequently,the software can be recalled or updated over the network, making post-releaseupdates easy to deploy.
The BREW Marketplace
The list of commercial wireless operators that have adopted BREW is growingsteadily. In the United States, Verizon Wireless and ALLTEL have adopted theplatform, while U.S. Cellular is in the midst of commercial trials. Verizon andALLTEL alone represent a potential market of approximately 41 millionsubscribers!
Outside the US, deployments of the BREW solution continue. KTF in SouthKorea, KDDI in Japan, and China Unicom have launched commercial, BREW-basedservices. In Latin America, Vivo, a joint venture between Portugal Telecom andSpain’s Telefonica Moviles rolled out BREW services in March of 2003. Telstra Corporation, Australia’s largest wireless service provider, alsoannounced the launch of its BREW-based services in March.
The table below summarizes key information about each of these operators.All of the implementations thus far have been on CDMA networks, which shouldcome as no surprise given QUALCOMM’s stewardship of the technology. That said,BREW is equally capable of running on a GSM network — i.e. BREW doesn’t careabout the air interface. China Unicom, for example, has a GSM network servicingfar more subscribers than its CDMA network (so far), yet the operator haselected to market BREW as an upscale service exclusively available on its CDMAnetwork.
Operator | Country | Total Subscribers (includes non-BREW) | Commercially Supported Handsets |
ALLTEL | USA | 7.8 million | Kyocera QCP 3035, Toshiba CDM9500, Motorola T720 |
China Unicom | China | 75.6 million | Kyocera KZ-820, Sanyo SCP-550 |
KDDI | Japan | 13.9 million | Toshiba A5304T |
KTF | South Korea | 10.3 million | More than 30 different handsets, too numerous to list. Partial list. |
Vivo (a joint venture between Portugal Telecom and Telefonica Moviles) | Brazil | 17 million | Audiovox CDM9500 |
Verizon Wireless | USA | 33.2 million | Kyocera QCP 3035, LGE VX-10, Motorola T720, Toshiba CDM9500, LGE VX-4400 |
Telstra | Australia | 6.2 million | Samsung A561 |
Clearly, the worldwide market for BREW applications is significant.
The table below shows key properties of each of the BREW handsets currentlyavailable in North America. The trend toward color screens with greaterdimensions is evident. Despite the trend, even the largest of these screensrepresent a user interface design challenge. I cover BREW user-interfaces indetail in other articles. Additional details about each of these phones areavailable to
Handset | Photo | Operators | Approx. Commercial Release Date | BREW Version | Display | Air Interface |
Kyocera 3225 | ALLTEL | First Quarter 2003 | 1.2† | 2 bit color depth, 106 x 98 pixels. | IS95, 1X | |
Kyocera QCP3035e | ALLTEL, Verizon | Second Quarter 2002 (non-BREW version released earlier) | 1.0 | Monochrome, 88 x 99 pixels | IS95A | |
LGE VX-10 | Verizon | Fourth Quarter 2002 | 1.1 | 2 bit color depth, 120 x 88 pixels | IS95, 1X | |
LGE VX-4400 | Verizon | First Quarter 2003 | 1.1 | 16 bit color depth, 120 x 115 pixels | 1X | |
Motorola T720 | Verizon | Fourth Quarter 2002 | 1.1 | 12 bit color depth, 120 x 130 pixels | IS95B, 1X | |
Toshiba CDM7900 | U.S. Cellular | In trial only. | 1.0 | 8 bit color depth, 128 x 144 pixels | IS95 | |
Toshiba / Audiovox CDM9500 | ALLTEL, U.S. Cellular, Verizon | Fourth Quarter 2002 / First Quarter 2003 | 1.1 | 16 bit color depth, 144 x 158 pixels | IS95, 1X | |
†Developers should use the BREW 1.1 SDK to target this phone. Note that SDK 1.0 can also be used to target phones equipped with later versions of the AEE. |
One of the primary advantages of BREW is the code portability it affords thedeveloper. Specifically, for a given BREW AEE version (see Which SDK ShouldI Choose? below), an application interacts with largely the same set ofBREW APIs on each targeted device. Nonetheless, a developer must be mindful of differencesin physical display dimensions and operator-specific limitations imposed onBREW implementations. For example, one operator might permit BREW applicationsto initiate a voice call while another may not.
Detailed information pertaining to each of the handsets listed above isavailable to authenticated developers on the BREW Developer Extranet.
What Do I Need to BREW?
Developers can create BREW applications using Java, XML, and Flash, thoughI have not used any of these myself. That said, C/C++ is native to BREW. Forthat reason, my articles focus on BREW development using C and C++.
Microsoft Visual C++ version 6.0, or higher, is required in order to buildan application that will run on the BREW Emulator that is supplied with theSDK.
Developer
In order for your application to run on actual hardware (i.e. a BREW phone),you must compile your source code using an ARM compiler. This step is necessarysince all the phones currently available employ ARM7TDMI processor cores. Thus,the .dll produced by Visual C++ only gets your code running on theWindows-based BREW Emulator, while an ARM Compiler is required to generate thecorresponding instructions for the handset.
ARM Developer Suite (ADS) version 1.2 and
A lot of initial development and testing can be completed using only theBREW Emulator. Due to significant differences between the emulator and actualhardware, however, developers are well advised to include frequent nativebuilds and testing on BREW handsets early in the development process. Thus, noserious BREW developer can get by without at least one BREW phone. Dependingupon the handset and operator chosen, the cost can range from $49.99 (with aminimum 2 year contract) to approximately $400, without a contract.
The following table summarizes what is needed to take an application fromconcept to TRUE BREW testing readiness.
Requirement | Approximate Cost |
ARM RealView Compilation Tools | $1,500 |
Authentication | $400 |
BREW SDK | FREE |
Handset | $50 – $400 (depending upon activation choice) |
Visual C++ | $109 (VC++ Standard) – $1,000 (Visual Studio Professional) |
Which SDK Should I Choose?
There are currently three versions of the BREW SDK, namely 1.0,1.1, and 2.0. Presently, only versions 1.0 and 1.1 of the AEE have beendeployed on commercially available handsets. Applications created using aparticular SDK version will run on handsets equipped with an AEE of the same orsubsequent version. There is no guarantee, however, that an applicationdeveloped using version 2.0 of the SDK will run on a phone equipped withversion 1.x of the AEE (nor should you expect an app. developed using SDK 1.1to run on an AEE 1.0 phone), simply because the later SDK providesfunctionality that is not supported by an earlier version of the executionenvironment. The bottom line is: do your development with the SDK thatcorresponds with the lowest common denominator in AEE terms. In this way, youensure that the correct libraries are used. The table in the following section,The SDK Tools, contains some tips pertaining to components of the 2.0SDK that can (and should) be used, regardless of which AEE version you aretargeting.
As of this writing (April 2003), phones with version 1.1 of the AEE haveonly been commercially deployed during the last few months, and some are stillawaiting commercial release. Handsets equipped with version 2.0 are expectedduring the first half of 2003.
Clearly, in order to maximize the size of the target market, a developershould use the oldest available version of the SDK (i.e. version 1.0). In thisway, the application should run on all handsets, current and future. That said,the choice also must take into account the incremental functionality offered bysubsequent SDK and AEE versions. For example, if your application depends uponfunctionality implemented only in version 2.0 of the AEE, you must use version2.0 of the SDK in its development. A developer so constrained will simply haveno revenue expectation until phones equipped with version 2.0 of the AEE arereleased.
For details regarding the features offered by later versions of the SDK, I suggestthat you peruse the BREW API Reference provided with version 1.0 of the SDK,then check the “What’s New” links associated with each of thesubsequent versions (start
Tip: ensure that you read the ReadMe file for each release asyou might otherwise miss some crucial information. For example, if you onlyread the SDK 1.0 API Reference, you will be unaware of the entire ILicenseinterface’s existence as it is documented only in the ReadMe file forthat release.
The SDK Tools
The tools included with each version of the SDK are summarized in thefollowing table.
BREW SDK Tool | In SDK v. | Purpose |
MIF Editor | 1.x, 2.0 | Every BREW application requires a Module Information File (.mif) so that it can be loaded by the AEE, both on the emulator and on an actual handset. The .mif contains application-specific information like its unique class ID, its privileges and its icons. Privileges specify the application’s ability to access certain functionality on the device or on the operator’s network. For example, in BREW 1.0, the following privileges can be specified: File, Network, Position Location, TAPI†, and Write Access to Shared Directory. Your application will not run if it tries to use any of the associated API’s without having the proper privileges in place. Tip: improper privilege settings in a .mif file can be one of the most insidious errors to track down. Figure 2 shows the error message that is displayed on the emulator if your application attempts to create a file without having the File privilege turned on. When you see a priv error, it means that you must enable the associated privilege in the .mif file. Tip: the MIF Editor included with the 2.0 SDK includes a command line interface that can help you work more efficiently. This tool can also be used with a 1.x SDK, just make sure you save the file in the correct format. SDK Reference: BREW MIF Editor Guide. |
Resource Editor | 1.x, 2.0 | BREW resources are made available to applications in BREW Applet Resource (.bar) files. Resources can include strings, images, and dialogs consisting of various user interface elements such as menus and text controls. The Resource Editor is used to specify and define these resources. The Resource Editor’s native files have a .bri extension (BREW Resource Intermediate). After the resources have been specified, the Resource Editor is used to compile them, thereby producing two files: the .bar file and a C header file containing the #defined resource ID’s for all the resource elements. The .bar file is used both by the emulator (see below) and on phones. The header file must be #included in the application’s source file. Tip: the Resource Editor in 2.0 also includes a command line interface and it can be used in conjunction with 1.x-based development. SDK Reference: BREW Resource Editor Guide. |
Device Configurator | 1.x, 2.0 | The Device Configurator can be used to create a new phone configuration file (.qsc) that the BREW Emulator (see below) employs to model the behavior of a specific device. Things like the screen size and the amount of heap memory available on a device can be specified using the Configurator. Tip: use the Configurator to reduce the amount of available heap space on an emulated handset so that an application’s behavior can be modeled under low memory conditions. SDK Reference: BREW Device Configurator Guide. |
Emulator | 1.x, 2.0 | The BREW Emulator runs the .dll produced by Visual C++ in order to simulate the execution of your application on an actual device. The BREW Emulator included with the latest version of the SDK (2.0) includes special features. For example, it conducts rigorous heap checking that can help a developer track down errors that can cause an application to crash a device (e.g. memory leaks, out of bounds array accesses, etc.). Tip: you can run version 2.0 of the BREW Emulator, even if you are targeting 1.x devices with a 1.x SDK. SDK Reference: BREW SDK User’s Guide. The guide tells you where the application’s .bar, .mif and .dll files must be located in order for the emulator to properly enumerate and start your applet. |
Application Wizard | 1.1, 2.0 | The BREW Application Wizard generates a Visual C++ project, complete with essential project settings and a source file containing the skeleton code required by all BREW applications. It is a helpful tool but there are a couple of undocumented annoyances you should know about. Tip: Figure 3 shows how to set the location of the .dll target that represents your application. If you don’t make the change shown, the .dll will be placed within the project’s debug subdirectory and the emulator will be unable to start your application. Tip: Figure 4 shows how to set up Visual C++ so that you can start the emulator from within the IDE. This enables you to run the application in debug mode and take advantage of the features offered by the Visual C++ debugger. After the application wizard completes, just make the changes shown in Figures 3 and 4 to make your development environment work properly. |
PureVoice Converter | 1.1, 2.0 | The PureVoice Converter is a command line tool that converts WAV audio files to QUALCOMM PureVoice QCP files, the most compact digital format. SDK Reference: BREW Utilities Guide, Using the PureVoice Converter. |
BREW Compressed Image (BCI) Authoring Tool | 1.1, 2.0 | Compresses image files and enables the creation of animation sequences. SDK Reference: BREW Compressed Image Authoring Guide. |
2 Bit Bitmap Translator | 2.0 | Converts 4 bit bitmaps to 2 bit bitmaps for use on grayscale phones such as the Kyocera 3225 and the LG VX-10. SDK Reference: BREW Utilities Guide, Using the BREW 2 Bit Tool |
NMEA Logger Utility | 2.0 | NMEA stands for National Marine Electronics Association. The NMEA 0183 standard defines hardware data interfaces. BREW’s GPS implementation uses two of the discrete data unit formats, known as sentences, defined in the standard. These two different formats describe the layout of transmitted GPS data fields. This data is used in Location-Based Services (LBS) applications. The NMEA Logger utility provides a means of recording GPS Receiver output to a file for later use in the BREW Emulator. SDK References: BREW Utilities Guide, Using the NMEA Logger Utility and BREW SDK User’s Guide, Using the BREW Emulator. |
† TAPI stands for Telephony API. It provides the ability (depending upon the operator’s implementation) to programmatically initiate a call, obtain Calling Line ID (CLID), etc.. See the BREW API Reference. |
Originally published in the BREW Wireless Resource Center