What is BREW?

ByMurray Bonner
First of all, BREW?is an acronym that stands for Binary Runtime Environment for Wireless. From a software developer‘s perspective, Qualcomm?s BREW can be viewed as:
A set of APIs that enable developers to create software applications for wireless devices (wireless phones for now), and
A means of selling and delivering applications to end-users.
On the phone itself, BREW is a thin client (about 150K) that sits between a software application and the Application Specific Integrated Circuit (ASIC) level software. Thus developers can write to BREW without knowing or caring about the device‘s chipset or air interface. While it‘s true that CDMA is Qualcomm‘s specialty, BREW is equally capable of running on devices that employ other air interface standards. Figure 1 shows the conceptual layering of software on a wireless device.

The second major component of BREW is the BREW Distribution System (BDS). The BDS encompasses end users‘ ability to shop for, purchase, download, and install software over the wireless carrier‘s network.
The BREW Shop lets users browse the carrier‘s Application Download Server to see what applications are available for purchase or trial. The entire transaction is completed over the air. The carrier generates a billing record for each purchase and a corresponding charge appears on the subscriber‘s monthly phone bill.
The carrier retains any retail markup and shares 20% of the application‘s wholesale price with Qualcomm. The remaining 80% of the wholesale price flows to the developer.
Developing BREW Applications
BREW applications can be written using Java? C, or C++. At the 2002 BREW Developers Conference, held in early June in San Diego, IBM?and Insignia?demonstrated Java Virtual Machines for BREW. Hewlett Packard?(HP) has also ported its MicrochaiVM?to BREW. IBM will offer a BREW development plug-in with its WebSphere Studio Device Developer?product.
This series of articles will focus on C and C++ development for BREW, as supported by the freely availableBREW SDK. Note that there are presently 3 versions of the SDK available: 1.0, 1.1, and 2.0. Each SDK version is paired with a corresponding Application Execution Environment (AEE) on the phone. Applications written using the 1.0 SDK will run on phones equipped with later versions of the AEE. The converse is not necessarily true since each successive version incorporates new capabilities.
Since the provision of BREW updates for existing phones is unlikely, maintaining compatibility with version 1.0 is advisable if you want to maximize the size of your target market. Nonetheless, versions 1.1 and, particularly, 2.0 do offer significant incremental functionality. To learn more about the differences, download the 1.0 SDK and flip through the API Reference (754 pages). Then follow the 1.1 and 2.0 "What‘s new" links from thedownload page.
While it‘s true that the SDK is free of charge, the developer must have at least version 6.0 of Microsoft Visual C++?in order to develop and test applications using the BREW Emulator?supplied with the SDK. The emulator is a Windows?program that simulates the AEE on a phone. An application runs on the emulator as a Windows .dll. The emulator is a good tool for learning the APIs and testing an application throughout the development process. Be forewarned that there are significant differences between the emulator environment and the phone itself. Developers should incorporate actual hardware and frequent native builds early in the development process, in order to avoid convoluted debugging issues down the line.
When a developer decides to take the leap and commence commercial development, several additional costs must be incurred at various stages of the project. First of all, in order to gain access to tools fundamental to development on actual hardware, the developer must be authenticated. In essence, developer authentication involves an outlay of $400 for aVerisign Authentic Document Digital ID good for one year from date of purchase or the digital notarization of 100 applications, whichever comes first.
Authentication gives the developer access to the BREW Developer Extranet?where several important tools can be accessed and/or downloaded. For example, the BREW ClassID Generator?assures the provision of a unique, 32 bit ID for each application. The BREW TestSig Generator?provides a digital signature that allows a developer to test an application on actual hardware. Additionally, the BREW AppLoader?downloads applications onto phones.
Beyond authentication, there are other costs. The CPU used in BREW phones is currently an ARM7TDMI? Since C and C++ applications run natively on the device, an ARM?compiler is required. Qualcomm presently supports ARM BREW Builder?($1,500), ARM Developer Suite (ADS) 1.0.1? ADS1.1? and possibly ADS1.2? Given that ADS1.2 costs $5,500 for a node-locked license and $6,500 for a floating license, the $1,500 price tag for BREW Builder looks like a steal of a deal! A free, 45-day, evaluation version of ADS1.2 isavailable.
The developer will also need a BREW phone for testing applications. Presently only 2 models are commercially available: the Sharp?Z800?($399.99 from Verizon Wireless? and the Kyocera?QCP3035e (price unavailable, though certainly less than the Z800). Note that both of these phones have version 1.0 of the AEE, thus applications targeting these devices must be developed using version 1.0 of the SDK. Three new phones, equipped with version 1.1 of the AEE and a CDMA 1x air interface, are due to hit the market as early as September 2002. Pricing information is currently unavailable. Phones with version 2.0 of the AEE are expected late in 2002 or early in 2003.
As shown by Figure 2,TRUE BREW?certification testing, conducted by NSTL? represents another potentially significant cost for the developer. An application must pass TRUE BREW certification before a carrier will make it available on their network. Certification aims to ensure that carriers‘ networks remain free of viruses and malicious or unstable applications.
Figure 2 - Application Testing Charges
Privileges Required Standard  Expedited
Basic API functionality, file and shared directory access.$ 750.00$ 950.00
Above & data calls or Above & telephony/SMS (TAPI).1,500.001,900.00
Above & data calls & TAPI & position location.2,500.003,200.00
Functional testing required by some carriers, Add:400.00400.00
Getting to Profit
Once the developer has cleared TRUE BREW certification, a pricing plan must be negotiated with the carrier via a virtual marketplace maintained by Qualcomm. The plan involves several decisions, including the wholesale price per download as well as the type of license to grant to the end user.
Developers can choose to sell the application to end-users, charge a monthly subscription fee, or provide a free demo. When the sell option is chosen, the developer must further decide if the license is based upon a specified number of uses (an unlimited number is an option), an expiration date, a specified number of days of availability, or a fixed number of minutes of actual use. Demo options include 1-5 uses, 1-10 minutes of use, and 1-24 hours of elapsed time on the handset.
Once the developer and a carrier have agreed on a pricing plan, the carrier can make the application available to consumers by adding it to the BREW Shop catalog accessible from the handset.
Conclusion
Chipset independence, integrated distribution and billing features, and direct carrier involvement differentiate BREW from other wireless development contenders. BREW picks up where most APIs leave off - it provides a path to profit without requiring the developer to independently penetrate the "carrier barrier".
Next time: Getting Started with the BREW SDK.
About the Author
Murray Bonner is president of Golden Creek Software Inc.. The company specializes in wireless software development and is presently focused on preparing a BREW?application for TRUE BREW?certification. # # #
Next article:Getting Started with the BREW?SDK
Getting Started with the BREW?SDK
ByMurray Bonner
Part I - Preliminaries
If you wish to perform the steps outlined in this article, you require the following items:
Microsoft Visual C++ 6.0?/EM> or better, and
Version 1.1 of theBREW SDK.
To view the minimum system requirements and obtain specific, SDK installation instructions, view the SDK 1.1readme file. Note that I assume you have readWhat is BREW?, the previous article in this series.
Throughout this example, you need to know that file naming is important. Specifically, the application‘s module information file (.mif) must have the same name (i.e. prefix) as its .dll. In essense, with BREW you need to pick a name and stick with it! The significance of the .mif file suffix will become apparent as you read through this article. The next article will delve deeply into the creation of the .dll that runs on the BREW Emulator?
BREW Application Wizard
Version 1.1 of the SDK includes a BREW Application Wizard?that is not available in the version 1.0 release. This application wizard sets most of the applicable project options and produces the minimal skeleton code for a BREW Application, assuming you intend to do your development in C. The project settings and starter code are SDK 1.0 compliant. In the US, there are currently 4 BREW phones available: 2 equipped with version 1.0 of the BREW Application Execution Environment (AEE) and 2 with version 1.1. To ensure compatibility with all these phones, and those yet to be released, you will likely want to use version 1.0 of the SDK for development projects that you intend to commercialize. Should you decide on this course of action, you can use SDK 1.1 to generate your base project, then copy your application-specific files to a safe place, uninstall version 1.1 and download and install version 1.0 of the SDK for the remainder of your development. In this way, you can ensure that your application is version 1.0 compliant and therefore capable of running on current and future phones.
Figure 1
Once you have installed the SDK, open Visual C++ and click File > New. The New dialog should open with the Projects tab selected. As shown in Figure 1, select BREW Application Wizard, ensure that the path to \yourBREWdir\Examples is entered in the Location textbox, then enter "helloBREW" as the Project Name. Click OK to start the BREW Application Wizard. This should bring up the dialog pictured in Figure 2. For the simple application currently under construction, We don‘t need support for any of the items identified in this dialog. Thus, we can leave all of the checkboxes blank. Had we needed support for any of these items, it is important to realize that merely selecting the corresponding checkboxes in this dialog may not be sufficient. All that these checkboxes do is ensure that the proper interface header files are included in the source file generated by the wizard. The application must have the corresponding privilege level specified on the General tab of the BREW MIF Editor? The MIF Editor is discussed below and a screenshot of its default view is given in Figure 4. We‘ll discuss these privilege levels in detail when we cover the related interfaces in later articles. For now, click Next to proceed to the next step in the Application Wizard.
Figure 2
The MIF Editor
In step 2 of the wizard, a note reminds us that we need to create a Module Information File (.mif) for our BREW application. Click the button provided by the wizard to start the BREW MIF Editor.
Figure 3
On the Applets tab of the MIF Editor‘s main dialog, click the New Applet button to bring up the ClassID Generation dialog shown in Figure 3 (the terms applet and application are used interchangeably throughout this article). Note that the class ID must be unique. A quick perusal of the header files "AEEClassIDs.h", "AEEUsageAppIDs.h", and "AEESampleAppIDs.h" in the \yourBREWdir\inc\ directory shows that 0x1234ABCD does not conflict with any of the IDs included with the SDK. For a commercial application, we would need to obtain a globally unique ID from the BREW Developer Extranet For now, select Locally and type 1234ABCD, or any other non-conflicting ID, in the ClassID textbox. Click the Generate button and click Yes in response to the Are you sure you want to generate a ClassID locally? prompt.
In response to the Generate command, the MIF Editor creates a BREW ID (.bid) file. This file simply contains a #define for the class ID generated locally within the MIF Editor. In the next article, we‘ll ensure that "helloBREW.bid" is #included in the "helloBREW.c" source file. Figure 4 shows the Applets tab of the BREW MIF Editor. Except for the fact that we have not yet supplied a file for the Icon, your MIF Editor instance should appear as in Figure 4. Leave the MIF Editor open; we‘ll come back to it shortly.
Figure 4
Three bitmaps need to be included in the .mif file: one approximately 85 x 40 pixels, one 26 x 26 pixels, and a thumbnail image 16 x 16 pixels. You can create these bitmaps (.bmp) at any time using Microsoft Paint?or the resource editor within Visual Studio? Figure 5 shows the 85x40 pixel image I created using the latter tool. Obviously, you can use whatever images you please.
Figure 5
Once you‘ve finished the 3 bitmaps, save them and return to the MIF Editor where you can specify your 26x26 pixel image as the Icon. Next, click the Advanced button on the MIF Editor‘s Applets tab. The dialog displayed provides spaces to specify an Image and a Thumbnail Image. The Image is your 85x40 pixel bitmap and the Thumbnail Image is your 16x16 pixel bitmap. This example is intended for the Sharp Z800 phone which has a 128x144 pixel display and a maximum Image size of 108x72 pixels. Note that this maximum size applies only in this MIF Editor context. The dimensions of images based on the SDK‘s IImage interface are governed only by the device‘s physical screen size. Be aware that screen size and maximum Image dimensions vary from phone to phone. Detailed phone specifications are available to authenticated BREW developers via the BREW extranet. To gain an understanding of what is required to become an authenticated BREW developer, see theQualcomm?BREW website.
As an aside, you can create large images that end up displaying as animations on both the emulator and the phone. In this MIF Editor context, this is accomplished by simply creating a single bitmap consisting of several, horizontally arranged, identically-sized frames. Thus the total width of the bitmap can be greater than the device‘s display width, with the understanding that only one frame of the animation will be displayed at any given time. Note that, in order for this to work, the bitmap‘s width must be an exact multiple of its height.
Now that we‘ve created a basic module information file, we can close the MIF Editor and continue our exploration. Remember that it is essential for the .mif to have the same name (prefix) as the application‘s .dll. Note that the "helloBREW.mif" file just created must be copied to the ...\yourBREWdir\Examples\MIF\256Color\ directory in order for the AEE to find it and properly initialize the helloBREW application. This will become especially important next time, when we add our own source code to that generated by the BREW AppWizard and get the application running on the BREW Emulator?
The Resource Editor
Most applications require string and image resouces, not to mention some kind of user interface consisting of various screens. The BREW Applet Resource (.bar) file serves as your application‘s central repository for such items. Later in this series, we will work with image and user interface resources. For this introductory application, all we need is a simple resource file that contains two strings that we‘ll load and display at runtime. Start the Resource Editor by clicking the shortcut installed in your BREW program group. Figure 6 shows how the resource editor looks after the 2 strings have been entered. Initially the right pane of this dialog is empty.
Figure 6
To familiarize yourself with all the ins and outs of the resource editor, read the corresponding guide included with the SDK documentation. For now, right click in the left pane and select New String..., or simply use the keyboard shortcut, ALT-S. The dialog shown in Figure 7 is displayed. Use Figure 6 to fill in the contents of this dialog box for each of the required strings. Once the strings have been entered save the BREW Resource Intermediate (.bri) file as "helloBREW.bri" by selecting File > Save or clicking on the diskette icon on the tool bar. Note that you open the .bri file in the resource editor to make any changes. Whenever you create or edit an application‘s resources, you must click the blue ‘Q‘ icon on the tool bar after you are done. Doing so creates two files: "helloBREW.bar" and "helloBREW_res.h".
Figure 7
You must copy the "helloBREW_res.h" file to the ...\yourBREWdir\examples\helloBREW\ directory and #include it in "helloBREW.c". The "helloBREW.bar" file needs to be copied to the ...\yourBREWdir\Examples\en\256Color\ directory. As it runs on the emulator, the helloBREW application will access the string resources from "helloBREW.bar" on an "as required" basis. On a phone, at least in most non-trivial cases, an application will never need simultaneous access to all of its resources. Thus bulky strings, images, and UI elements can be relegated to the the phone‘s embedded file system (EFS) instead of consuming precious RAM. Additionally, the resource file concept eases the process of application internationalization.
Conclusion
In this article, three important BREW SDK tools have been introduced: the BREW Application Wizard, the BREW MIF Editor, and the BREW Resource Editor. The BREW Application Wizard created a skeletal BREW project that can be used as a baseline for our BREW application. The BREW MIF Editor created a module information file (.mif) that contains essential information such as our application‘s unique class ID, its category, and the images associated with each of the 3 icons required by most applications. The BREW Resource Editor was used to create our application‘s resources. These resources were then compiled into a BREW Applet Resource (.bar) file that serves up resources whenever the application requests them. Next time, we will disect the "helloBREW.c" source file as generated by the application wizard, add our own code to flesh out the application‘s simple functionality, and run the application using the BREW Emulator? Also, we‘ll see how to debug a BREW application using the Visual C++ debugger and the BREW Emulator.
Copyright 2002, Golden Creek Software Inc.
_xyz