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 here.

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 BREW WhitePaper.

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.

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 authenticatedBREW developers via the BREW Developer Extranet.

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 authenticationis required to gain access to various tools available on the BREW DeveloperExtranet. For example, the web-based digital test signature generator creates aphone-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 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 ARM RealView CompilationTools for BREW version 1.2 (formerly known as BREWBuilder) are currentlyavailable for purchase from ARM. Note that earlier versions of these tools willalso get the job done. Given that ADS costs $5,500 for a single user licenseand $6,500 for a floating license, the RealView Compilation Tools for BREW area 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 generationcapabilities needed to compile and link for the phone.

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.

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 here).

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.

Originally published in the BREW Wireless Resource Center