Intro: Getting Started With BREW

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 software applications targeting wireless handsets. The SDK is free of charge to software developers.  

For BREW applications to run on a phone, the BREW Application Execution Environment (AEE) must be present. The AEE is loaded onto phones by participating manufacturers, using the BREW Porting Kit.

Some operators require BREW applications to pass TRUE BREW testing before being made available to wireless subscribers. Testing, if required, is conducted by National Software Testing Laboratories (NSTL). More information on the testing process, including the costs, can be found here.

The BREW Distribution System (BDS) is a major component of the overall BREW solution that an operator uses to maintain a market in BREW applications. It enables subscribers to personalize their handsets by selecting applications and downloading them, over the air. A billing record is generated for each transaction and a corresponding line item appears on the subscriber's monthly bill. Herein lies BREW's biggest drawing card for developers -- the wireless operator and QUALCOMM handle all the distribution, billing and payment processing.  The developer receives 80% of the application's wholesale price from QUALCOMM.

The table below outlines BREW's value proposition.  BREW literally fuels its own success by fostering value and delivering incentive from one end of the business model to the other.  For software targeting wireless handsets, BREW represents an unprecedented, self-sustaining system.  For more detail, please read the BREW White Paper.

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 the client. This local processing advantage means BREW applications don't suffer from WAP's network latency issues. For this reason, BREW applications are more responsive. Thus, interactive, real time processing and graphic features can be incorporated, as evidenced by several of the games currently available for the BREW platform.

Connected BREW applications can download any required resources when an application starts, reducing the need for repeated, network-borne updates as processing proceeds. For example, assuming the presence of GPS services, a position location application can download a map from a web server when it is initialized, based on the subscriber's current locale. Subsequently, the device's own processing power can be used to graphically represent the user's location as GPS updates are received.

Before BREW, developing software for wireless phones meant an intensive, embedded development project for each targeted handset. BREW provides a relatively high level API that insulates the software developer from the hardware. Thus, porting software to different devices is a relatively simple task.

This brings us to the question "Is BREW better than J2ME?". To the extent that the two platforms overlap, proponents from each camp can put forth convincing arguments as to why one is better than the other. I'll leave those battles to the so inclined.

In fact, BREW and Java don't really compete. As Figure 1 shows, the two can coexist on the same device. Instead of eschewing BREW, Java developers should welcome it since it reduces the likelihood of experiencing Java code portability problems between different handsets. Traditionally, Java requires a different, chipset-specific virtual machine (JVM) for each targeted handset model. Now a single JVM can target multiple handsets since BREW provides an abstraction layer over the hardware. In essence, BREW acts as the virtual machine's virtual machine. Still, mostly due to devices' differing screen dimensions, Java on BREW doesn't quite achieve write once, run anywhere nirvana (neither does Java without BREW). In the mobile handset world, however, that elusive perfection 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) and Insignia Solutions (Mobile Foundation for BREW). Both JVM's require handsets equipped with version 2.0 of the BREW AEE. IBM is also adding integrated, BREW development support to WebSphere Studio Device Developer.

BREW's distribution system (BDS) makes it possible for a JVM (and any other software) to be downloaded and installed "on the fly", once the system has determined that the subscriber has suitable hardware. Subsequently, the software can be recalled or updated over the network, making post-release updates easy to deploy.

The BREW Marketplace
The list of commercial wireless operators that have adopted BREW is growing steadily. In the United States, Verizon Wireless and ALLTEL have adopted the platform, while U.S. Cellular is in the midst of commercial trials. Verizon and ALLTEL alone represent a potential market of approximately 41 million subscribers!

Outside the US, deployments of the BREW solution continue. KTF in South Korea, KDDI in Japan, and China Unicom have launched commercial, BREW-based services. In Latin America, Vivo, a joint venture between Portugal Telecom and Spain's Telefonica Moviles rolled out BREW services in March of 2003.  Telstra Corporation, Australia's largest wireless service provider, also announced 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 should come 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 care about the air interface. China Unicom, for example, has a GSM network servicing far more subscribers than its CDMA network (so far), yet the operator has elected to market BREW as an upscale service exclusively available on its CDMA network.

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 currently available in North America. The trend toward color screens with greater dimensions is evident. Despite the trend, even the largest of these screens represent a user interface design challenge. I cover BREW user-interfaces in detail in other articles. Additional details about each of these phones are available to authenticated BREW developers via the BREW Developer Extranet.

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 the developer. Specifically, for a given BREW AEE version (see Which SDK Should I Choose? below), an application interacts with largely the same set of BREW APIs on each targeted device. Nonetheless, a developer must be mindful of differences in physical display dimensions and operator-specific limitations imposed on BREW implementations. For example, one operator might permit BREW applications to initiate a voice call while another may not.

Detailed information pertaining to each of the handsets listed above is available to authenticated developers on the BREW Developer Extranet.

What Do I Need to BREW?

Developers can create BREW applications using Java, XML, and Flash, though I have not used any of these myself. That said, C/C++ is native to BREW. For that reason, my articles focus on BREW development using C and C++.

Microsoft Visual C++ version 6.0, or higher, is required in order to build an application that will run on the BREW Emulator that is supplied with the SDK.

Developer authentication is required to gain access to various tools available on the BREW Developer Extranet. For example, the web-based digital test signature generator creates a phone-specific, time limited file required to test an application on a phone. An application cannot run on a handset without one of these test signatures.

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 necessary since all the phones currently available employ ARM7TDMI processor cores. Thus, the .dll produced by Visual C++ only gets your code running on the Windows-based BREW Emulator, while an ARM Compiler is required to generate the corresponding instructions for the handset.

ARM Developer Suite (ADS) version 1.2 and ARM RealView Compilation Tools for BREW version 1.2 (formerly known as BREWBuilder) are currently available for purchase from ARM. Note that earlier versions of these tools will also get the job done. Given that ADS costs $5,500 for a single user license and $6,500 for a floating license, the RealView Compilation Tools for BREW are a pretty good value at $1,500 per user (a floating license is not an option). The RealView Compilation Tools for BREW lack some of ADS' bells and whistles (e.g. the CodeWarrior IDE) yet they include the same basic code generation capabilities needed to compile and link for the phone.

A lot of initial development and testing can be completed using only the BREW Emulator. Due to significant differences between the emulator and actual hardware, however, developers are well advised to include frequent native builds and testing on BREW handsets early in the development process. Thus, no serious BREW developer can get by without at least one BREW phone. Depending upon the handset and operator chosen, the cost can range from $49.99 (with a minimum 2 year contract) to approximately $400, without a contract.

The following table summarizes what is needed to take an application from concept 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 been deployed on commercially available handsets. Applications created using a particular SDK version will run on handsets equipped with an AEE of the same or subsequent version. There is no guarantee, however, that an application developed using version 2.0 of the SDK will run on a phone equipped with version 1.x of the AEE (nor should you expect an app. developed using SDK 1.1 to run on an AEE 1.0 phone), simply because the later SDK provides functionality that is not supported by an earlier version of the execution environment. The bottom line is: do your development with the SDK that corresponds with the lowest common denominator in AEE terms. In this way, you ensure that the correct libraries are used. The table in the following section, The SDK Tools, contains some tips pertaining to components of the 2.0 SDK that can (and should) be used, regardless of which AEE version you are targeting.

As of this writing (April 2003), phones with version 1.1 of the AEE have only been commercially deployed during the last few months, and some are still awaiting commercial release. Handsets equipped with version 2.0 are expected during the first half of 2003.

Clearly, in order to maximize the size of the target market, a developer should use the oldest available version of the SDK (i.e. version 1.0). In this way, the application should run on all handsets, current and future. That said, the choice also must take into account the incremental functionality offered by subsequent SDK and AEE versions. For example, if your application depends upon functionality implemented only in version 2.0 of the AEE, you must use version 2.0 of the SDK in its development. A developer so constrained will simply have no revenue expectation until phones equipped with version 2.0 of the AEE are released.

For details regarding the features offered by later versions of the SDK, I suggest that 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 the subsequent versions (start here).

Tip: ensure that you read the ReadMe file for each release as you might otherwise miss some crucial information. For example, if you only read the SDK 1.0 API Reference, you will be unaware of the entire ILicense interface's existence as it is documented only in the ReadMe file for that release.

The SDK Tools
The tools included with each version of the SDK are summarized in the following 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