brew report

8/7/2019 Brew Report

1/34

ABSTRACT

QUALCOMMs Binary Runtime for Wireless Environment (BREW) provides apowerful framework for creating exciting applications on a wide variety of mobile

devices. By using this guide, you will become familiar with the BREW development

environment and BREW technology. The guide walks you through the steps necessary to

install the BREW SDK, develop BREW applications, and load those applications into

a handset. Solutions are presented for the most common problems encountered during

each step of the process; additional resources for solving other issues pertinent to each

phase of development are also listed. It will also provide the advantage and disadvantage

of BREW.

Department Of computer Science & Engineering 4


2/34


3/34

1. INTRODUCTION

BREW is an application development platform created by Qualcomm for mobile

phones. It was originally developed forCDMA handsets, but has since been ported to

other air interfaces including GSM/GPRS, and UMTS. Standing for Binary Runtime

Environment for Wireless, it is a software platform that can download and run small

programs for playing games, sending messages, sharing photos, etc. The main advantage

of BREW platform is that the application developers can easily port their applications

between all the Qualcomm ASICs.

The BREW runs between the application and the wireless device's chip operating system

so as to enable a programmer to develop applications without needing to code for system

interface or understand wireless applications. It debuted in September2001.

QUALCOMMs Binary Runtime for Wireless Environment (BREW) provides a

powerful framework for creating exciting applications on a wide variety of mobile

devices. By using this guide, you will become familiar with the BREW development

environment. The guide walks you through the steps necessary to install the BREWSDK, develop BREW applications, and load those applications into a handset.

Solutions are presented for the most common problems encountered during each step of

the process; additional resources for solving other issues pertinent to each phase of

development are also listed. It will also provide the advantage and disadvantage of

BREW.

http://en.wikipedia.org/wiki/Qualcommhttp://en.wikipedia.org/wiki/Telephonehttp://en.wikipedia.org/wiki/Telephonehttp://en.wikipedia.org/wiki/CDMAhttp://en.wikipedia.org/wiki/GSMhttp://en.wikipedia.org/wiki/GPRShttp://en.wikipedia.org/wiki/UMTShttp://en.wikipedia.org/wiki/ASIChttp://en.wikipedia.org/wiki/2001http://en.wikipedia.org/wiki/Qualcommhttp://en.wikipedia.org/wiki/Telephonehttp://en.wikipedia.org/wiki/Telephonehttp://en.wikipedia.org/wiki/CDMAhttp://en.wikipedia.org/wiki/GSMhttp://en.wikipedia.org/wiki/GPRShttp://en.wikipedia.org/wiki/UMTShttp://en.wikipedia.org/wiki/ASIChttp://en.wikipedia.org/wiki/2001


4/34

2. WHAT IS BREW

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:

1. A set of APIs that enable developers to create software applications for wireless

devices (wireless phones for now), and

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



5/34

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 softwareover 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 pricewith Qualcomm. The remaining 80% of the wholesale price flows to the developer.



6/34

3. DEVELOPING BREW APPLICATION

BREW applications can be written using Java, C, or C++. At the 2002 BREWDevelopers 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 available BREW 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.

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 throughoutthe 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

https://brewx.qualcomm.com/developer/sdk/download.jsphttps://brewx.qualcomm.com/developer/sdk/download.jsp


7/34

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 a Verisign 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 is available.

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

http://www.verisign.com/products/brew/index.htmlhttp://www.arm.com/devtools/ads_eval?OpenDocumenthttp://www.verizonwireless.com/ics/plsql/brew_shop.phoneshttp://www.verisign.com/products/brew/index.htmlhttp://www.arm.com/devtools/ads_eval?OpenDocumenthttp://www.verizonwireless.com/ics/plsql/brew_shop.phones


8/34

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.00 1,900.00

Above & data calls & TAPI & position location. 2,500.00 3,200.00

Functional testing required by some carriers, Add: 400.00 400.00

Software for the BREW-enabled handsets can be developed in C orC++ using the freely

downloadable BREW SDK. The SDK includes a BREW Emulator, or starting with

BREW Version 3.0 and above, the BREW Simulator, which can be used for testing

during the development process. Unlike the Java ME platform, where any developer can

upload and execute software on any supported handset, BREW applications must be

digitally signed. Because BREW gives complete control over the handset hardware, only

content providers orauthenticated BREW developers have the tools necessary to create a

digital signature. Furthermore, developer-signed applications can only execute on test-

http://www.qualcomm.com/brew/developer/developing/apptesting.htmlhttp://en.wikipedia.org/wiki/C_(programming_language)http://en.wikipedia.org/wiki/C++https://brewx.qualcomm.com/brew/sdk/download.jsphttp://en.wikipedia.org/wiki/SDKhttp://en.wikipedia.org/wiki/Emulatorhttp://en.wikipedia.org/wiki/Java_MEhttp://brew.qualcomm.com/brew/en/developer/resources/gs/get_auth.htmlhttp://www.qualcomm.com/brew/developer/developing/apptesting.htmlhttp://en.wikipedia.org/wiki/C_(programming_language)http://en.wikipedia.org/wiki/C++https://brewx.qualcomm.com/brew/sdk/download.jsphttp://en.wikipedia.org/wiki/SDKhttp://en.wikipedia.org/wiki/Emulatorhttp://en.wikipedia.org/wiki/Java_MEhttp://brew.qualcomm.com/brew/en/developer/resources/gs/get_auth.html


9/34

enabled handsets (BREW version 3.1 and newer devices are already "test-enabled") .

Once the application has been developed and internally tested, it must be submitted to

NSTL forTRUE BREW Testing. After the application passes all tests, it may be offered

to a mobile operator (content provider) to be accessible fordownload to general handsets.

The application is then signed by the content provider, to allow its execution on any

supported BREW handset.

The BREW Emulator (currently called Brew Simulator) does not emulate handset's

hardware. Instead, the BREW application is compiled to native code and linked with a

x86-compatible BREW runtime library. Because of this, obscure platform bugs related to

memory alignment and various firmware related glitches make debugging applications

without a BREW handset difficult. Developers must test their applications on real

BREW-enabled handsets. To do that, the handset must be enabled for BREW testing

(Qualcomm's development labs can do the service). Starting from BREW 3.1, test-enable

bit functionality was removed, and now all that is needed is a developer's digital

signature.

For testing purpose, BREW applications can be transferred using a USB orserial cable toany BREW-compatible handset using BREW AppLoader from Qualcomm. A BREW

application contains several components which must be present, otherwise it will be

automatically deleted on reboot. This includes a name.mif file which describes the

application, the features it uses and permissions requested, a name.modfile which is the

actual compiled binary, name.barwhich contains string and image resources if required,

and a name.sigwhich is the application digital signature. Applications which do not have,

or have an invalid or expired digital signature, are automatically deleted on reboot.

BREW Applications may be unloaded from a consumer handset to save handset memory

space. This is referred to as "Disable/Restore", and is a requirement of the TRUE BREW

Test Cycle. Saved files are kept intact using Disable/Restore, and it is possible to re-load

the application without paying for it again. In a "Disable" situation, all .bar, .mod,

https://www.nstl.com/nstl/index.htmhttp://brew.qualcomm.com/brew/en/developer/resources/bd/ext_test.htmlhttp://en.wikipedia.org/wiki/Downloadhttp://en.wikipedia.org/wiki/X86http://en.wikipedia.org/wiki/Digital_signaturehttp://en.wikipedia.org/wiki/Digital_signaturehttp://en.wikipedia.org/wiki/USBhttp://en.wikipedia.org/wiki/Serial_cablehttps://www.nstl.com/nstl/index.htmhttp://brew.qualcomm.com/brew/en/developer/resources/bd/ext_test.htmlhttp://en.wikipedia.org/wiki/Downloadhttp://en.wikipedia.org/wiki/X86http://en.wikipedia.org/wiki/Digital_signaturehttp://en.wikipedia.org/wiki/Digital_signaturehttp://en.wikipedia.org/wiki/USBhttp://en.wikipedia.org/wiki/Serial_cable


10/34

and .sig files are deleted from the handset, while any other files remain in their originalplace. During the "Restore" operation, the .bar, .mod, and.sig files are downloaded from

the carrier's mobile store, and the previously disabled application will have full

functionality remaining. The Disable/Restore process is only available to consumer users

once the handset's memory is completely full.

Once the application passes testing, it's available to carriers, but this does not guarantee

that any carrier will make it available to end users. Carriers have to be persuaded to offer

the application to end users.

BREW developers are required to register with Qualcomm, and to submit their

applications for TRUE BREW Testing at significant additional cost. Before submitting

for testing, the application needs to be signed. As of March 2006, the least expensive

digital signature for testing costs 400 USD and is limited to 100 application submissions.

This steep cost of entry excludes hobbyists from developing for phones that use BREW.

After all these hurdles have been cleared, there is still a high risk that carriers will reject

the application as insufficiently profitable, or as a competitor to one of their own

applications.

http://en.wikipedia.org/wiki/As_of_2006http://en.wikipedia.org/wiki/United_States_dollarhttp://en.wikipedia.org/wiki/Hobbyisthttp://en.wikipedia.org/wiki/As_of_2006http://en.wikipedia.org/wiki/United_States_dollarhttp://en.wikipedia.org/wiki/Hobbyist


11/34

4. BUSSINESS MODEL IMPLICATION

Time to market can take longer with BREW than with J2ME because of BREW'srigorous certification requirements. This certification process may be perceived as an

advantage by established software developers because the difficulties associated with

testing and development costs create a high cost of entry to developers with low budgets

and little time, resulting in less market dilution. Specifically, developers ofcasual games

run less risk of having to compete with freeware workalikes developed and self-published

by hobbyists.

After an application is written it takes two weeks per iteration of True BREW

testing (each time the application fails the test).

Next, negotiations with carrier(s) commence.

Then, (if successful) the carrier will spend time retesting the application with their

own tests on their network.

Finally, rolling out a new version means starting the process over again.

Currently, most developers choose to support both J2ME and BREW, or only J2ME.

J2ME may offer a lower cost to market because some carriers allow non-certified J2ME

applications to run on their phones. J2ME is widely used in Europe, while BREW is

primarily used in the U.S. and Japan. Even in the U.S., J2ME phones have a larger

market share than BREW enabled phones. One of the initial advantages of BREW was

that Verizon made it easy to purchase applications from the phone, while most J2ME

carriers did not. However, most carriers of J2ME phones now offer easy-to-access

purchasing portals.

There are now commercial technologies to fully automate porting from J2ME to BREW.

This reduces the entry barrier to produce BREW applications by eliminating the need to

develop two versions of the same application in both Java and C/C++.

http://en.wikipedia.org/wiki/Time_to_markethttp://en.wikipedia.org/wiki/Casual_gamehttp://en.wikipedia.org/wiki/Freewarehttp://en.wikipedia.org/wiki/Clone_(computer_and_video_games)http://en.wikipedia.org/wiki/Time_to_markethttp://en.wikipedia.org/wiki/Casual_gamehttp://en.wikipedia.org/wiki/Freewarehttp://en.wikipedia.org/wiki/Clone_(computer_and_video_games)


12/34

5. BREW SDK

5.1 INTRODUCTION

Five versions of the BREW SDK are currently available for download: 1.0, 1.1, 2.0, 2.1,

and 3.0. Depending on your targeted platform and the capabilities required by your

application, you may need to download and install multiple versions of the SDK. Patches

for many of the SDK installations are available for download on the same page as the

SDK, and you should install them as appropriate. Note that devices may not support all

interfaces included with the SDK. By inspecting the appropriate Device Data Sheets

(DDS), ensure that the desired device supports all APIs necessary for the application

under development. To ensure compatibility with the mobile device, you should perform

all development in the same or lower SDK release as the version of BREW used by the

device. BREW devices are backwards compatible; that is, any applications written in a

previous version of the SDK function on later versions of BREW.

This section provides a brief overview of the features of each version of the SDK,

including any major changes made to the API collection. For more information on the

specific API additions, consult the Release Notes for the desired SDK, which are

available on the installation page. Many APIs are enhanced with additional functionality

with each new release; the BREW SDK APIs by Version guide gives a complete listing

of the methods available under a given version of an interface, including the general SDK

helper functions provided. Detailed method usage information for each API is available

through the, included in the SDK download package. BREW API Reference

After you identify the SDK versions necessary to develop the desired platforms, youinstall them from the SDK download page along with the corresponding patches. Obtain

a CD-ROM containing the SDK installation packages free of charge by contacting brew-

[email protected] be sure to include full shipping information in your request.



13/34

BREW SDK 1.0

No BREW 1.0 devices are currently available commercially. Previously available

handsets implementing BREW 1.0 include the Motorola V731 and Sharp Z800.

BREW SDK 1.1

BREW 1.1 has a widely established user base, with the continued commercial availability

devices of BREW 1.1 devices. Some of the more prominent examples in this category are

the Motorola T-720 and LGE VX4400.

BREW SDK 2.0

Example devices in this category are the LGE VX6000, Kyocera SE47 (Slider), and

Samsung SCH-A670.

BREW SDK 2.1

The example device in this category is the Toshiba CDM-990.



14/34

5.2 INSTALLING BREW SDK

From the BREW SDK download page, select the desired version of the BREW SDK and

clickInstall. A web-based installer guides you through the installation process.

Installation Directory

Generally, it is best to install the BREW SDK to the default directory specified by the

installer. Changing the installation directory does not have an adverse impact in most

cases, though in BREW 1.x installing to a directory containing a . (period) may cause

issues when executing the Emulator.

NOTE: The Emulator was changed to Simulator in the SDK 3.0 and will henceforth be

referred to as the Simulator.

BREWDIR

During the installation process, you are prompted to set/update the BREWDIR

environment variable, or leave it unchanged. Microsoft Visual Studio, as well as

makefiles generated by the BREW Add-Ins for Microsoft Visual Studio, uses this

environment variable. For practical purposes, it should be set to the directory of the SDK

intended for the majority of development work. If multiple versions of the BREW SDK

are installed on an individual computer, the BREWDIR variable must be changed prior to

beginning development in each version of the SDK. If the environment variable is not

changed, it is necessary to modify makefiles generated by the secondary BREW SDK

installations; the developer manually adds the proper versions of the BREW API librariesto new BREW applications created using the application wizard.



15/34

Common issues

System requirements

If your computer fails to meet the minimum system requirements, the BREW SDK

installation fails.

1 Internet Explorer version 5.5 SP2 or higher with 128-bit encryption

2 Windows NT 4.0, Windows 2000, or Windows XP

3 Administrator privileges for your computer

The BREW SDK is currently available for installation on Windows platforms only; due

to the requirement for Unicode text encoding capabilities, Windows 9x and ME are not

supported.

Additional resources

Please address any problems with accessing the SDK download page to brew-

[email protected]. Be sure to include a detailed description of the problem

encountered as well as any pertinent error messages.



16/34

5.3 WRITING BREW APPLICATION

This guide assumes that development is performed within the Microsoft Visual Studio 6.0

environment, which is the officially supported development studio. Authoring BREW

applications using later versions of Microsoft Visual Studio (Visual Studio .NET) is also possible.

Consult the Creating BREW Applications Using Visual Studio .NET guide for specifics

on importing BREW projects into the Visual Studio .NET environment.

This section presents an overview of the BREW development process, including the basic steps

necessary to write a functional BREW application. For a more in-depth tutorial on writing your

first BREW application refer to the Creating a BREW Application from Scratch document,

which details the creation of an application with key handling and resource files.

Creating a new application with the BREW Application

Wizard

The BREW Application Wizard facilitates the creation of new BREW projects by providing a

generic code framework for your application. The wizard is automatically installed with BREW

SDK 1.1 and above. To use the BREW Application Wizard, launch Microsoft Visual Studio and

clickFile>New to create a new project (File New). The BREW Application Wizard appears

within the available project type menu (see Figure 1 Invoking the BREW Application Wizard ).

Enter the desired project name and location and clickOKto start the wizard.

NOTE: To function properly on all versions of BREW, filenames should not contain uppercase

letters. Filenames containing uppercase characters are not allowed on the mobile device;

additionally, they cause errors during emulation in BREW SDK 3.0+. Your applications name

must begin with alphabetical characters; applications downloaded over the air have MIF and

directory names containing only numbers, and BREW treats these files differently. For example,

an application directory named helloworld is renamed as something similar to 1234 when

downloaded over the air. Failing to follow this convention may lead to fatal errors in your



17/34

application. Additionally, note that it is not safe to assume that you will know the name of your

MIF file or application directory when the application has been downloaded to a device over the

air.



18/34

Figure 1 Invoking the BREW Application Wizard

The first step in the Application Wizard is to specify the interfaces your application uses

(see Figure 2. BREW Application Wizard step 1). Checking boxes within this window

inserts a #include preprocessor directive within your source code, providing access to the

API methods supporting the specified functionality. You need to provide additional

#include directives for any other header files required by the APIs used in the application

(see theBREW API Reference for this information).NOTE: Selecting support for interfaces within the Application Wizard is not equivalent

to specifying privilege levels within the application MIF. If your application requires

privileges, you must specify the appropriate access rights using the MIF Editor. See



19/34

Setting privileges for details. Find information on the privilege levels required for various

APIs within the corresponding section of theBREW API Reference.

Figure 2. BREW Application Wizard step 1

After adding support for the desired interfaces, clickNext to advance the wizard to the

second and final step (see Figure 3. BREW Application Wizard step 2).



20/34

Figure 3. BREW Application Wizard step 2

Alternatively, you can clickFinish to create your project immediately, without disabling

pre-generated source code comments. In this step, the wizard prompts you to launch the

BREW MIF Editor to create a MIF for your module. The MIF contains important

information about the classes and applications supported by a module, such as the applet

name and icon. While you may start application development before you create a MIF,

you must do so before testing the application within the Simulator or loading to a mobile

device; see Using the BREW MIF Editor for details. You may also opt to disable the

automatic generation of source code comments, though you may find the comments

helpful in developing your first BREW applications. After you click Finish, the wizard

completes its processes, and a window appears, summarizing the actions taken in the next

step.



21/34

Figure 4. New Project Information window

To view the newly created code, close the New Project Information window, and open

the helloworld.c file (the name of this file will depend on the name of your project) from

the project workspace File View (). The wizard-generated code is presented below, with a

description of the important sections.



22/34

Figure 5. New project workspace

NOTE: If you are developing your application for a version of the BREW SDK located

in a directory other than the location specified by the BREWDIR environment variable,

the AEEAppGen.c, AEEModGen.c, and libraries linked with your application will be

incorrect. To remedy this error, you must manually replace the files in your project with

the correct version (a tedious and error-prone process), or change the value of the

BREWDIR variable. Changing the value of the BREWDIR is the preferred solution, as

the project may later be safely compiled under other versions of the SDK by simply

updating the environment variable.

Changing the BREWDIR environment variable

The BREWDIR variable is modified through the Environment Variables section of your

computers System Properties. Right-click on My Computer > Properties > Advanced >

Environment Variables to access the window. Scroll down through the list of user

variables until you find the entry for BREWDIR. This should be set to the root directory

of the target SDK installation (see Figure 6. Modifying environment variables).

NOTE: If you change the BREWDIR environment variable while an application usingthe variable is running (for example, an MS-DOS command prompt or Visual Studio),

you must close and reopen that application for the changes to take effect.



23/34

Figure 6. Modifying environment variables



24/34

Skeletal code generated by the BREW ApplicationWizard

The wizard generated code is included below. Important sections of the code(numbered) are discussed afterwards

/

*======================================================================

===

FILE: helloworld.c

=======================================================================

==*/

/

*======================================================================

===

INCLUDES AND VARIABLE DEFINITIONS

=======================================================================

= */

#include "AEEModGen.h" // Module interface definitions 1#include "AEEAppGen.h" // Applet interface definitions

#include "AEEShell.h" // Shell interface definitions

#include "helloworld.bid" 2

/*-------------------------------------------------------------------

Applet structure. All variables in here are reference via "pMe->"

-------------------------------------------------------------------*/

typedef struct _helloworld { 3AEEApplet a ; // First element of this structure must be AEEApplet

AEEDeviceInfo DeviceInfo; // always have access to the hardware device

information

IDisplay *pIDisplay; // give a standard way to access the Display

interface

IShell *pIShell; // give a standard way to access the Shell interface

// add your own variables here...

} helloworld;

/*-------------------------------------------------------------------

Function Prototypes

-------------------------------------------------------------------*/

static boolean helloworld_HandleEvent(helloworld* pMe, AEEEvent eCode,

uint16 wParam, uint32 dwParam);

boolean helloworld_InitAppData(helloworld* pMe);

void helloworld_FreeAppData(helloworld* pMe);

/

*======================================================================

===

FUNCTION DEFINITIONS

=======================================================================

= */

/*======================================================================



25/34

FUNCTION: AEEClsCreateInstance

======================================================================*

/

4int AEEClsCreateInstance(AEECLSID ClsId, IShell *pIShell, IModule *po,

void **ppObj)

{

*ppObj = NULL;

if( ClsId == AEECLSID_HELLOWORLD )

{

// Create the applet and make room for the applet structure

if( AEEApplet_New(sizeof(helloworld),

ClsId,

pIShell,

po,

(IApplet**)ppObj,

(AEEHANDLER)helloworld_HandleEvent,(PFNFREEAPPDATA)helloworld_FreeAppData) )

// the FreeAppData function is called after sending EVT_APP_STOP to the

HandleEvent

// function

{

//Initialize applet data, this is called before sending EVT_APP_START

// to the HandleEvent function

if(helloworld_InitAppData((helloworld*)*ppObj))

{

//Data initialized successfully

return(AEE_SUCCESS);

}

else

{//Release the applet. This will free the memory allocated for the

applet when

// AEEApplet_New was called.

IAPPLET_Release((IApplet*)*ppObj);

return EFAILED;

}

} // end AEEApplet_New

return(EFAILED);

}

/

*======================================================================

===

FUNCTION SampleAppWizard_HandleEvent

=========================================================================*/

5static boolean helloworld_HandleEvent(helloworld* pMe, AEEEvent eCode,

uint16 wParam, uint32 dwParam)

{

switch (eCode)

{

// App is told it is starting up



26/34

case EVT_APP_START:

// Add your code here...

return(TRUE);

// App is told it is exiting

case EVT_APP_STOP:


return(TRUE);

// App is being suspended

case EVT_APP_SUSPEND:


return(TRUE);

// App is being resumed

case EVT_APP_RESUME:


return(TRUE);

// An SMS message has arrived for this app. Message is in the dwParam

above as

// (char *)// sender simply uses this format "//BREW:ClassId:Message", example

//BREW:0x00000001:Hello World

case EVT_APP_MESSAGE:


return(TRUE);

// A key was pressed. Look at the wParam above to see which key was

pressed. The key

// codes are in AEEVCodes.h. Example "AVK_1" means that the "1" key was

pressed.

case EVT_KEY:


return(TRUE);

// If nothing fits up to this point then we'll just break out

default:break;

}

return FALSE;

}

6// this function is called when your application is starting up

boolean helloworld_InitAppData(helloworld* pMe)

{

return TRUE;}

7// this function is called when your application is exitingvoid helloworld_FreeAppData(helloworld* pMe){

}}



27/34

API library includes1

To use the methods in a particular BREW API, the corresponding header file must be

included in your application. Information on the necessary header files for each API is

contained within the BREW API Reference.

NOTE: To prevent the introduction of static and global data, do not link standard C

libraries to your BREW application. As such, standard C library routines (for instance,

strcat (), malloc (), sprintf ()) cannot be used within BREW. Helper functions are

provided for the most commonly used C functions; see the API Reference BREW for

more details. Additionally, floating-point operations may only be performed through the

floating-point helper functions. These limitations are the result of the ARM platform, not

BREW itself.

Class ID file2

Before compiling your application, you must generate a class ID file. This file contains aunique 32-bit identification code (8-digit hexadecimal value), which is used by

the BREW interface creation mechanism. For testing on a local system, it is

sufficient to generate a local class ID through the MIF Editor, though

QUALCOMM must issue a unique ID to applications intended for distribution.

For more information on obtaining class ID files, see the Using the BREW MIF

Editor.

Applet structure3

Any objects used during the lifetime of your application should be placed within the

applet structure. As static and global variables are not permitted within BREW, the applet

structure provides a mechanism for achieving similar behavior. The applet structure is



28/34


29/34

indicate successful handling, or FALSE if the event is not handled. Event codes

supported by BREW (AEE Events) are listed within the Data Types section of the BREW

API Reference Programming Concepts Guide. Consult the BREWfor more information

on event-handling rules and principles in BREW.

Applet data init method6

This method is used to perform any initialization code required by the applet. Typically,

this function is used to instantiate the members of your applet structure or allocate

memory for buffers, returning a Boolean value to indicate whether the process was

successful. By placing all your allocation code in a single method, you reduce the

potential for neglecting to properly instantiate a member of the applet structure.

Applet data free method7

The applet data free method is used for deallocation of all resources and any additional

procedures required for the application to safely terminate. In general, this is

accomplished by calling the corresponding XXX_Release () method for objects that were

instantiated through ISHELL_CreateInstance (), using FREE () on memory allocated

through MALLOC(), and canceling all pending timers. All resource allocations

performed in your applets data initialization method should be deallocated within this

method.



30/34

6. ADVANTAGE OF BREW

The following list specifically compares BREW to J2ME. While J2ME is certainly more

resistant to crashing than BREW, from a game development point of view, there are

several advantages to BREW.

The BREW API is more standard across supported phones than the J2ME API,

which can be considerably different depending on the phone model.

The API tends to be cleaner than J2ME, and many of the recent API changes have

made BREW very game friendly.

Graphics tricks are easier, especially with BREW 2.0 and direct access to the

screen buffer.

J2ME phones often have an artificial limit to the size of the binary (128KB is

common). This isn't present with BREW.

BREW applications can use Object-oriented programming. In J2ME the filesize

overhead for extra classes encourages C-like programming. In addition, because

arrays of non-primitive types are actually arrays of references, there is significant

memory overhead in J2ME for arrays of classes. To get around this, parallel

arrays of primitive types are often used in J2ME.

Provisioning is a part of the platform, integrating reporting and various forms of

billing (one-time/recurring/etc)

The development environment is standardized, comes with free tools, and

contains a well integrated emulator that properly reflects the behaviour of the

actual device (J2ME emulators vastly differ in reliability, performance,integration, and ease of use. J2ME developers are forced to debug using OEM

specific emulators, use a variety of customized build scripts and/or purchase

expensive 3rd party solutions).

http://en.wikipedia.org/wiki/J2MEhttps://brewx.qualcomm.com/bws/content/gi/docs/brew_api_reference/brew3.1/en/online/BREW_API_Reference/APIChart/APIChart.htmhttp://en.wikipedia.org/wiki/J2MEhttps://brewx.qualcomm.com/bws/content/gi/docs/brew_api_reference/brew3.1/en/online/BREW_API_Reference/APIChart/APIChart.htm


31/34

Once a BREW application is working in the emulator there is a high probability itwill work on all BREW devices. This may offset the additional expense of NSTL

testing fees since the debugging cycle may be quicker. That said, however,

different phones may implement some aspects of the BREW API and other

standards differently and debugging such issues can be difficult since the

emulator tends to be more generic.

Brew applications perform much faster. For common non-computationally

intensive tasks the disparity may not be too noticeable. However, J2ME

performance is quite poor, in comparison, when attempting time critical tasks.

Being embedded on the chipset and connected to a tight and secure distribution

network gives BREW advantages over J2MEs more generic security model.

BREW capabilities and APIs, especially in BREW 3 and above, allow BREW to

interact with a broad array of phone functions seamlessly. While available to

some J2ME environments as well, BREW is defined to have access to the phone

file system, APIs to interact with telephone functions, capabilities to evaluate the

phone's "state" in a number of different areas and dimensions. Also, BREW

allows foreground and background running of tasks, and applications can run

concurrently.

BREW applications use a predefined model for pricing, revenue shares and

financial transactions.



32/34

7. DISADVATAGE OF BREW

In J2ME, the entire source file and resources are compressed by default. To

compress resources with BREW, you have to roll your own solution. The same is

true of BREW code, it can only be compressed if you devise your own method or

buy a commercial solution. However, this may be of little concern since BREW

devices lack the tight memory restrictions imposed by J2ME.

Commercial profilers for C/C++ are expensive, whereas the J2ME environment

comes with a profiler. However, free open source C/C++ profilers for Linux are

readily available.

The BREW developer community is fairly small and limited to Qualcomm's

boards and web sites. There are not many books available either.

http://en.wikipedia.org/wiki/Performance_analysishttp://en.wikipedia.org/wiki/Performance_analysis


33/34

8. 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".



34/34

9. REFERENCES

www.qualcomm.com

www.google.com

www.altavista.com

For specific information about BREW [email protected]

BREW Developer Forums, where developers from around the world discuss a

wide variety of issues related to the BREW environment.
http://www.qualcomm.com/http://www.google.com/http://www.altavista.com/mailto:[email protected]:[email protected]://www.qualcomm.com/http://www.google.com/http://www.altavista.com/mailto:[email protected]

brew report

Documents