You are on page 1of 34


QUALCOMM’s 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 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



• • •

6 7 9 14 15 15 17 19 33 35 36 37



Department Of computer Science & Engineering


BREW is an application development platform created by Qualcomm for mobile phones. It was originally developed for CDMA 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 September 2001. QUALCOMM’s 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 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


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. WHAT IS BREW First of all. BREW is equally capable of running on devices that employ other air interface standards. Qualcomm®'s BREW can be viewed as: 1. A means of selling and delivering applications to end-users. Figure 1 shows the conceptual layering of software on a wireless device. From a software developer's perspective. Department Of computer Science & Engineering 7 . On the phone itself. and 2. A set of APIs that enable developers to create software applications for wireless devices (wireless phones for now). While it's true that CDMA is Qualcomm's specialty. BREW™ is an acronym that stands for Binary Runtime Environment for Wireless.2.

Department Of computer Science & Engineering 8 . The BREW Shop lets users browse the carrier's Application Download Server to see what applications are available for purchase or trial. The carrier retains any retail markup and shares 20% of the application's wholesale price with Qualcomm. The entire transaction is completed over the air. and install software over the wireless carrier's network. purchase. download. The carrier generates a billing record for each purchase and a corresponding charge appears on the subscriber's monthly phone bill.The second major component of BREW is the BREW Distribution System (BDS). The BDS encompasses end users' ability to shop for. The remaining 80% of the wholesale price flows to the developer.

3. the developer must have at least version 6. and 2. IBM will offer a BREW development plug-in with its WebSphere Studio Device Developer™ product. The emulator is a good tool for learning the APIs and testing an application throughout the development process. Note that there are presently 3 versions of the SDK available: 1. Nonetheless. versions 1.0 SDK and flip through the API Reference. in order to avoid Department Of computer Science & Engineering 9 . The converse is not necessarily true since each successive version incorporates new capabilities. held in early June in San Diego.1. download the 1.0 of Microsoft Visual C++™ in order to develop and test applications using the BREW Emulator™ supplied with the SDK. particularly.1 and. While it's true that the SDK is free of charge. At the 2002 BREW Developers Conference. Each SDK version is paired with a corresponding Application Execution Environment (AEE) on the phone. IBM® and Insignia® demonstrated Java Virtual Machines for BREW. Hewlett Packard® (HP) has also ported its MicrochaiVM™ to BREW. DEVELOPING BREW APPLICATION BREW applications can be written using Java™. as supported by the freely available BREW SDK.0 is advisable if you want to maximize the size of your target market. Be forewarned that there are significant differences between the emulator environment and the phone itself. Applications written using the 1. Since the provision of BREW updates for existing phones is unlikely. maintaining compatibility with version 1. 1. C.dll. 2.0. An application runs on the emulator as a Windows .0 SDK will run on phones equipped with later versions of the AEE. Developers should incorporate actual hardware and frequent native builds early in the development process. or C++. To learn more about the differences. This series of articles will focus on C and C++ development for BREW. The emulator is a Windows™ program that simulates the AEE on a phone.0 do offer significant incremental functionality.0.

the developer must be authenticated. though certainly less than the Z800). For example. In essence.500 for a floating license. 45-day. whichever comes first. The CPU used in BREW phones is currently an ARM7TDMI®. Three new Department Of computer Science & Engineering 10 .500 for a node-locked license and $6.2 costs $5. First of all. 32 bit ID for each application.0 of the AEE. Presently only 2 models are commercially available: the Sharp® Z800™ ($399. Note that both of these phones have version 1. The developer will also need a BREW phone for testing applications.500). an ARM® compiler is required. The BREW TestSig Generator™ provides a digital signature that allows a developer to test an application on actual hardware. Given that ADS1. good for one year from date of purchase or the digital notarization of 100 applications.1™. the BREW ClassID Generator™ assures the provision of a unique. Beyond authentication. there are other costs. in order to gain access to tools fundamental to development on actual hardware. and possibly ADS1. evaluation version of ADS1.500 price tag for BREW Builder looks like a steal of a deal! A free.1™.0 of the SDK.0.convoluted debugging issues down the line. the BREW AppLoader™ downloads applications onto phones. developer authentication involves an outlay of $400 for a Verisign Authentic Document Digital ID™. Additionally. Since C and C++ applications run natively on the device. the $1. Authentication gives the developer access to the BREW Developer Extranet™ where several important tools can be accessed and/or downloaded. ARM Developer Suite (ADS) 1. Qualcomm presently supports ARM BREW Builder™ ($1.99 from Verizon Wireless®) and the Kyocera® QCP3035e (price unavailable. ADS1. When a developer decides to take the leap and commence commercial development. several additional costs must be incurred at various stages of the project.2™. thus applications targeting these devices must be developed using version 1.2 is available.

500. The SDK includes a BREW Emulator. Furthermore.00 2. equipped with version 1.00 400. are due to hit the market as early as September 2002.00 Software for the BREW-enabled handsets can be developed in C or C++ using the freely downloadable BREW SDK.00 1. Figure 2 . developer-signed applications can only execute on testDepartment Of computer Science & Engineering 11 .phones. An application must pass TRUE BREW certification before a carrier will make it available on their network. conducted by NSTL™. TRUE BREW™ certification testing. Above & data calls & TAPI & position location. BREW applications must be digitally signed. the BREW Simulator.00 3. Add: Standard $ 750.00 400. or starting with BREW Version 3. Functional testing required by some carriers. Because BREW gives complete control over the handset hardware. only content providers or authenticated BREW developers have the tools necessary to create a digital signature.200.1 of the AEE and a CDMA 1x air interface. Phones with version 2.Application Testing Charges Privileges Required Basic API functionality. As shown by Figure 2. Unlike the Java ME platform.900.0 of the AEE are expected late in 2002 or early in 2003.00 1.500. Certification aims to ensure that carriers' networks remain free of viruses and malicious or unstable applications.0 and above. Above & data calls or Above & telephony/SMS (TAPI).00 Expedited $ 950. file and shared directory access. which can be used for testing during the development process. where any developer can upload and execute software on any supported handset. represents another potentially significant cost for the developer. Pricing information is currently unavailable.

the handset must be enabled for BREW testing (Qualcomm's development labs can do the service). and a name. all . Once the application has been developed and internally which contains string and image resources if required. Developers must test their applications on real BREW-enabled handsets. This includes a name.mod.1. After the application passes all tests. Because of this. and it is possible to re-load the application without paying for it again. In a "Disable" situation. to allow its execution on any supported BREW handset. . the BREW application is compiled to native code and linked with a x86-compatible BREW runtime library. This is referred to as "Disable/Restore".1 and newer devices are already "test-enabled") . or have an invalid or expired digital signature. BREW Applications may be unloaded from a consumer handset to save handset memory space. a name. For testing purpose. otherwise it will be automatically deleted on reboot. BREW applications can be transferred using a USB or serial cable to any BREW-compatible handset using BREW AppLoader from Qualcomm. Starting from BREW 3. it may be offered to a mobile operator (content provider) to be accessible for download to general handsets. Saved files are kept intact using Disable/Restore.sig which is the application digital signature. A BREW application contains several components which must be To do that. the features it uses and permissions requested. test-enable bit functionality was removed. it must be submitted to NSTL for TRUE BREW Testing.mod file which is the actual compiled binary. and is a requirement of the TRUE BREW Test Cycle. and now all that is needed is a developer's digital signature.mif file which describes the application. are automatically deleted on reboot. Instead. Applications which do not have. obscure platform bugs related to memory alignment and various firmware related glitches make debugging applications without a BREW handset difficult.enabled handsets (BREW version 3. The BREW Emulator (currently called Brew Simulator) does not emulate handset's hardware. The application is then signed by the content provider. Department Of computer Science & Engineering 12 . name.

The Disable/Restore process is only available to consumer users once the handset's memory is completely full.mod. and. the least expensive digital signature for testing costs 400 USD and is limited to 100 application submissions.sig files are downloaded from the carrier's mobile store. and the previously disabled application will have full functionality remaining.sig files are deleted from the handset. but this does not guarantee that any carrier will make it available to end users. Department Of computer Science & Engineering 13 . Once the application passes testing. while any other files remain in their original place. it's available to carriers. the . Carriers have to be persuaded to offer the application to end users. and to submit their applications for TRUE BREW Testing at significant additional or as a competitor to one of their own applications. This steep cost of entry excludes hobbyists from developing for phones that use BREW. As of March 2006. Before submitting for testing. the application needs to be signed. After all these hurdles have been cleared. . During the "Restore" operation. there is still a high risk that carriers will reject the application as insufficiently profitable.and . BREW developers are required to register with Qualcomm.

J2ME may offer a lower cost to market because some carriers allow non-certified J2ME applications to run on their phones. Department Of computer Science & Engineering 14 . Finally.S. or only J2ME. most developers choose to support both J2ME and BREW. Then. rolling out a new version means starting the process over again. and Japan.S. 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. Even in the U. (if successful) the carrier will spend time retesting the application with their own tests on their network. One of the initial advantages of BREW was that Verizon made it easy to purchase applications from the phone. • • • Currently.4. There are now commercial technologies to fully automate porting from J2ME to BREW. BUSSINESS MODEL IMPLICATION Time to market can take longer with BREW than with J2ME because of BREW's rigorous certification requirements. 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++. However. Next. while BREW is primarily used in the U. negotiations with carrier(s) commence. J2ME is widely used in Europe. resulting in less market dilution.. while most J2ME carriers did not. J2ME phones have a larger market share than BREW enabled phones. developers of casual games run less risk of having to compete with freeware workalikes developed and self-published by hobbyists. most carriers of J2ME phones now offer easy-to-access purchasing portals. Specifically. • After an application is written it takes two weeks per iteration of True BREW testing (each time the application fails the test).

5. ensure that the desired device supports all APIs necessary for the application under development. included in the SDK download package. 1. BREW SDK 5. This section provides a brief overview of the features of each version of the SDK. including the general SDK helper functions provided. Patches for many of the SDK installations are available for download on the same page as the SDK. which are available on the installation page.0. Department Of computer Science & Engineering 15 . By inspecting the appropriate Device Data Sheets (DDS). Note that devices may not support all interfaces included with the SDK. that is. any applications written in a previous version of the SDK function on later versions of BREW. For more information on the specific API additions.0. you install them from the SDK download page along with the corresponding patches. you may need to download and install multiple versions of the SDK. the BREW SDK APIs by Version guide gives a complete listing of the methods available under a given version of an interface. and 3. 2. Many APIs are enhanced with additional functionality with each new release.1. 2. Detailed method usage information for each API is available through the. BREW API Reference After you identify the SDK versions necessary to develop the desired platforms. Depending on your targeted platform and the capabilities required by your be sure to include full shipping information in your request. Obtain a CD-ROM containing the SDK installation packages free of charge by contacting brewsupport@qualcomm. and you should install them as appropriate. consult the Release Notes for the desired SDK.1 INTRODUCTION Five versions of the BREW SDK are currently available for download: 1. BREW devices are backwards compatible.1. including any major changes made to the API collection. 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.0.

0 devices are currently available commercially.1 The example device in this category is the Toshiba CDM-990. BREW SDK 2.1 has a widely established user base.1 BREW 1.0 Example devices in this category are the LGE VX6000.0 include the Motorola V731 and Sharp Z800. and Samsung SCH-A670. BREW SDK 1. Some of the more prominent examples in this category are the Motorola T-720 and LGE VX4400. with the continued commercial availability devices of BREW 1.BREW SDK 1. Kyocera SE47 (Slider). Previously available handsets implementing BREW 1.0 No BREW 1.1 devices. BREW SDK 2. Department Of computer Science & Engineering 16 .

For practical purposes. BREWDIR During the installation process. NOTE: The Emulator was changed to Simulator in the SDK 3. as well as makefiles generated by the BREW Add-Ins for Microsoft Visual Studio. you are prompted to set/update the BREWDIR environment variable. it should be set to the directory of the SDK intended for the majority of development work.2 INSTALLING BREW SDK From the BREW SDK download page. If multiple versions of the BREW SDK are installed on an individual computer. Installation Directory Generally.x installing to a directory containing a ‘. the BREWDIR variable must be changed prior to beginning development in each version of the SDK. though in BREW 1.0 and will henceforth be referred to as the Simulator. or leave it unchanged. A web-based installer guides you through the installation process. it is necessary to modify makefiles generated by the secondary BREW SDK installations. If the environment variable is not changed. 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. Department Of computer Science & Engineering 17 . select the desired version of the BREW SDK and click Install. Microsoft Visual Studio.5. the developer manually adds the proper versions of the BREW API libraries to new BREW applications created using the application wizard.’ (period) may cause issues when executing the Emulator. uses this environment variable.

the BREW SDK installation fails.Common issues System requirements If your computer fails to meet the minimum system requirements.0. Additional resources Please address any problems with accessing the SDK download page to brewsupport@qualcomm. 1• Internet Explorer version 5. Be sure to include a detailed description of the problem encountered as well as any pertinent error messages. Windows 9x and ME are not supported.5 SP2 or higher with 128-bit encryption 2• Windows NT 4. Department Of computer Science & Engineering 18 . or Windows XP 3• Administrator privileges for your computer The BREW SDK is currently available for installation on Windows platforms only. Windows 2000. due to the requirement for Unicode text encoding

NET) is also possible. launch Microsoft Visual Studio and click File>New to create a new project (File → New). additionally. The wizard is automatically installed with BREW SDK 1. Consult the Creating BREW™ Applications Using Visual Studio . applications downloaded over the air have MIF and directory names containing only numbers.5. they cause errors during emulation in BREW SDK 3. and BREW treats these files differently.NET guide for specifics on importing BREW projects into the Visual Studio . For a more in-depth tutorial on writing your first BREW application refer to the Creating a BREW™ Application from Scratch document. Your application’s name must begin with alphabetical characters. an application directory named helloworld is renamed as something similar to 1234 when downloaded over the air. The BREW Application Wizard appears within the available project type menu (see Figure 1 Invoking the BREW Application Wizard ). which is the officially supported development studio. Authoring BREW applications using later versions of Microsoft Visual Studio (Visual Studio . filenames should not contain uppercase letters.3 WRITING BREW APPLICATION This guide assumes that development is performed within the Microsoft Visual Studio 6. Enter the desired project name and location and click OK to start the wizard. NOTE: To function properly on all versions of BREW.1 and above. For example. which details the creation of an application with key handling and resource files.0 environment. including the basic steps necessary to write a functional BREW application. Failing to follow this convention may lead to fatal errors in your Department Of computer Science & Engineering 19 .0+.NET environment. Filenames containing uppercase characters are not allowed on the mobile device. This section presents an overview of the BREW development process. 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. To use the BREW Application Wizard.

Additionally. Department Of computer Science & Engineering 20 .application. 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.

See Department Of computer Science & Engineering 21 . you must specify the appropriate access rights using the MIF Editor. Checking boxes within this window inserts a #include preprocessor directive within your source code. BREW Application Wizard step 1).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. If your application requires privileges. providing access to the API methods supporting the specified functionality. NOTE: Selecting support for interfaces within the Application Wizard is not equivalent to specifying privilege levels within the application MIF. You need to provide additional #include directives for any other header files required by the APIs used in the application (see the BREW API Reference for this information).

click Next to advance the wizard to the second and final step (see Figure 3. Figure 2. BREW Application Wizard step 2). Department Of computer Science & Engineering 22 .Setting privileges for details. Find information on the privilege levels required for various APIs within the corresponding section of the BREW API Reference. BREW Application Wizard step 1 After adding support for the desired interfaces.

you must do so before testing the application within the Simulator or loading to a mobile device. the wizard prompts you to launch the BREW MIF Editor to create a MIF for your module. such as the applet name and icon. Department Of computer Science & Engineering 23 . BREW Application Wizard step 2 Alternatively. you can click Finish to create your project immediately. After you click Finish. summarizing the actions taken in the next step. without disabling pre-generated source code comments. see Using the BREW MIF Editor for details. the wizard completes its processes. The MIF contains important information about the classes and applications supported by a module. You may also opt to disable the automatic generation of source code comments. In this step. and a window appears.Figure 3. though you may find the comments helpful in developing your first BREW applications. While you may start application development before you create a MIF.

Figure 4. with a description of the important sections. and open the helloworld. New Project Information window To view the newly created code. Department Of computer Science & Engineering 24 . close the New Project Information window.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.

c. you must manually replace the files in your project with the correct version (a tedious and error-prone process). Changing the value of the BREWDIR is the preferred solution. NOTE: If you change the BREWDIR environment variable while an application using the variable is running (for example. 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. Right-click on My Computer > Properties > Advanced > Environment Variables to access the window. as the project may later be safely compiled under other versions of the SDK by simply updating the environment variable. Modifying environment variables). the AEEAppGen. Scroll down through the list of user variables until you find the entry for BREWDIR. or change the value of the BREWDIR variable.c. This should be set to the root directory of the target SDK installation (see Figure 6. Department Of computer Science & Engineering 25 . you must close and reopen that application for the changes to take effect. AEEModGen.Figure 5. an MS-DOS command prompt or Visual Studio). and libraries linked with your application will be incorrect. To remedy this error. Changing the BREWDIR environment variable The BREWDIR variable is modified through the Environment Variables section of your computer’s System Properties.

Figure 6. Modifying environment variables Department Of computer Science & Engineering 26 .

// First element of this structure must be AEEApplet AEEDeviceInfo DeviceInfo.. boolean helloworld_InitAppData(helloworld* pMe). Important sections of the code (numbered) are discussed afterwards / *====================================================================== === FILE: helloworld. / *====================================================================== === FUNCTION DEFINITIONS ======================================================================= = */ /*====================================================================== Department Of computer Science & Engineering 27 . // always have access to the hardware device information IDisplay *pIDisplay. AEEEvent eCode. All variables in here are reference via "pMe->" -------------------------------------------------------------------*/ typedef struct _helloworld { AEEApplet a .bid" 1 2 3 /*------------------------------------------------------------------Applet structure. /*------------------------------------------------------------------Function Prototypes -------------------------------------------------------------------*/ static boolean helloworld_HandleEvent(helloworld* pMe.c ======================================================================= ==*/ / *====================================================================== === INCLUDES AND VARIABLE DEFINITIONS ======================================================================= = */ #include "AEEModGen.. uint32 dwParam).h" // Applet interface definitions #include "AEEShell.h" // Module interface definitions #include "AEEAppGen. uint16 wParam.Skeletal code generated by the BREW Application Wizard The wizard generated code is included below. } helloworld.h" // Shell interface definitions #include "helloworld. void helloworld_FreeAppData(helloworld* pMe). // give a standard way to access the Shell interface // add your own variables here. // give a standard way to access the Display interface IShell *pIShell.

pIShell. } } // end AEEApplet_New return(EFAILED). uint32 dwParam) (eCode) is told it is starting up Department Of computer Science & Engineering 28 . ClsId. po. return EFAILED. this is called before sending EVT_APP_START // to the HandleEvent function if(helloworld_InitAppData((helloworld*)*ppObj)) { //Data initialized successfully return(AEE_SUCCESS). } / *====================================================================== === FUNCTION SampleAppWizard_HandleEvent ======================================================================= ==*/ 5 static uint16 { switch { // App boolean helloworld_HandleEvent(helloworld* pMe. } else { //Release the applet. IShell *pIShell. (IApplet**)ppObj. wParam. (AEEHANDLER)helloworld_HandleEvent. void **ppObj) { *ppObj = NULL. (PFNFREEAPPDATA)helloworld_FreeAppData) ) // the FreeAppData function is called after sending EVT_APP_STOP to the HandleEvent // function { //Initialize applet data. AEEEvent eCode. IAPPLET_Release((IApplet*)*ppObj).FUNCTION: AEEClsCreateInstance ======================================================================* / 4 int AEEClsCreateInstance(AEECLSID ClsId. if( ClsId == AEECLSID_HELLOWORLD ) { // Create the applet and make room for the applet structure if( AEEApplet_New(sizeof(helloworld). IModule *po. This will free the memory allocated for the applet when // AEEApplet_New was called.

// App is being resumed case EVT_APP_RESUME: // Add your code here..... // If nothing fits up to this point then we'll just break out default: break.. // An SMS message has arrived for this app. } return FALSE... example //BREW:0x00000001:Hello World case EVT_APP_MESSAGE: // Add your code here. case EVT_KEY: // Add your code here. // App is told it is exiting case EVT_APP_STOP: // Add your code here. return(TRUE). } 6 // this function is called when your application is starting up boolean helloworld_InitAppData(helloworld* pMe) { return TRUE. Look at the wParam above to see which key was pressed. return(TRUE). Message is in the dwParam above as // (char *) // sender simply uses this format "//BREW:ClassId:Message"... // App is being suspended case EVT_APP_SUSPEND: // Add your code here. return(TRUE). return(TRUE)... return(TRUE) EVT_APP_START: // Add your code here. The key // codes are in AEEVCodes.. Example "AVK_1" means that the "1" key was pressed. return(TRUE). // A key was pressed. } 7 // this function is called when your application is exiting void helloworld_FreeAppData(helloworld* pMe) { } } Department Of computer Science & Engineering 29 .

it is sufficient to generate a local class ID through the MIF Editor. standard C library routines (for instance. though QUALCOMM must issue a unique ID to applications intended for distribution. NOTE: To prevent the introduction of static and global data.API library includes 1 To use the methods in a particular BREW API. do not link standard C libraries to your BREW application. Helper functions are provided for the most commonly used C functions. sprintf ()) cannot be used within BREW. malloc (). This file contains a unique 32-bit identification code (8-digit hexadecimal value). For more information on obtaining class ID files. Information on the necessary header files for each API is contained within the BREW API Reference. the applet structure provides a mechanism for achieving similar behavior. Applet structure 3 Any objects used during the lifetime of your application should be placed within the applet structure. you must generate a class ID file. not BREW itself. As static and global variables are not permitted within BREW. As such. Class ID file 2 Before compiling your application. The applet structure is Department Of computer Science & Engineering 30 . Additionally. floating-point operations may only be performed through the floating-point helper functions. which is used by the BREW interface creation mechanism. the corresponding header file must be included in your application. strcat (). see the API Reference BREW for more details. These limitations are the result of the ARM platform. For testing on a local system. see the Using the BREW MIF Editor.

which is registered in the call to AEEAppletNew () within the AEEClsCreateInstance () method. Within this method AEEAppletNew () is called. All initialization activities specific to your application are performed in your data initialization function. Consolidating all allocations and deallocations decreases the chance of memory access errors and memory leaks. where the application performs the appropriate actions. Event handler 5 All BREW applications must contain an event handling function. In the BREW event-handling environment. the elements of the applet are all initialized within the applications data initialization method. registering the event handler. BREW automatically invokes this routine to create an instance of your applet in memory prior to sending the EVT_APP_START.received as a parameter in most BREW methods. it should not be necessary to modify the AEEClsCreateInstance () method. events must be handled within a limited timeframe. Events are passed to this function by the BREW layer. After receiving an event. and data deallocation functions. which allows access to the structure members. data initialization (optional). AEEClsCreateInstance () method 4 This is a required method for all applications. Typically. and deallocated in the application’s data free method. NOTE: The first element of your applet structure must be an AEEApplet object so the AEEApplet_New () method can properly initialize your applet. and all processing must be completed before the next event may be received. the handler code should return TRUE to Department Of computer Science & Engineering 31 .

indicate successful handling. returning a Boolean value to indicate whether the process was successful. using FREE () on memory allocated through MALLOC(). Typically. Applet data free method 7 The applet data free method is used for deallocation of all resources and any additional procedures required for the application to safely terminate. this is accomplished by calling the corresponding XXX_Release () method for objects that were instantiated through ISHELL_CreateInstance (). Applet data init method 6 This method is used to perform any initialization code required by the applet. and canceling all pending timers. All resource allocations performed in your applet’s data initialization method should be deallocated within this method. By placing all your allocation code in a single method. In general. this function is used to instantiate the members of your applet structure or allocate memory for buffers. Event codes supported by BREW (AEE Events) are listed within the Data Types section of the BREW API Reference Programming Concepts Guide. you reduce the potential for neglecting to properly instantiate a member of the applet structure. or FALSE if the event is not handled. Consult the BREW for more information on event-handling rules and principles in BREW. Department Of computer Science & Engineering 32 .

While J2ME is certainly more resistant to crashing than BREW. To get around this. J2ME developers are forced to debug using OEM specific emulators. and many of the recent API changes have made BREW very game friendly. comes with free tools. The API tends to be cleaner than J2ME. and contains a well integrated emulator that properly reflects the behaviour of the actual device (J2ME emulators vastly differ in reliability. because arrays of non-primitive types are actually arrays of references.6. This isn't present with BREW.0 and direct access to the screen buffer. BREW applications can use Object-oriented programming. there are several advantages to BREW. performance. integration. parallel arrays of primitive types are often used in J2ME. J2ME phones often have an artificial limit to the size of the binary (128KB is common). • Department Of computer Science & Engineering 33 . which can be considerably different depending on the phone model. In addition. use a variety of customized build scripts and/or purchase expensive 3rd party solutions). ADVANTAGE OF BREW The following list specifically compares BREW to J2ME. • • • • • Provisioning is a part of the platform. In J2ME the filesize overhead for extra classes encourages C-like programming. • The BREW API is more standard across supported phones than the J2ME API. Graphics tricks are easier. from a game development point of view. there is significant memory overhead in J2ME for arrays of classes. integrating reporting and various forms of billing (one-time/recurring/etc) The development environment is standardized. especially with BREW 2. and ease of use.

BREW capabilities and APIs. APIs to interact with telephone functions. however. in comparison. • BREW applications use a predefined model for pricing. However. • Brew applications perform much faster. That said. BREW allows foreground and background running of tasks. Also. especially in BREW 3 and above.• Once a BREW application is working in the emulator there is a high probability it will work on all BREW devices. For common non-computationally intensive tasks the disparity may not be too noticeable. 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. While available to some J2ME environments as well. BREW is defined to have access to the phone file system. and applications can run concurrently. revenue shares and financial transactions. J2ME performance is quite poor. when attempting time critical tasks. • Being embedded on the chipset and connected to a tight and secure distribution network gives BREW advantages over J2ME’s more generic security model. capabilities to evaluate the phone's "state" in a number of different areas and dimensions. Department Of computer Science & Engineering 34 . This may offset the additional expense of NSTL testing fees since the debugging cycle may be quicker. allow BREW to interact with a broad array of phone functions seamlessly.

you have to roll your own solution. Department Of computer Science & Engineering 35 . it can only be compressed if you devise your own method or buy a commercial solution. DISADVATAGE OF BREW • In J2ME. However. whereas the J2ME environment comes with a profiler. To compress resources with BREW. • The BREW developer community is fairly small and limited to Qualcomm's boards and web sites.7. However. There are not many books available either. free open source C/C++ profilers for Linux are readily available. the entire source file and resources are compressed by default. • Commercial profilers for C/C++ are expensive. The same is true of BREW code. this may be of little concern since BREW devices lack the tight memory restrictions imposed by J2ME.

BREW picks up where most APIs leave off . Department Of computer Science & Engineering 36 . and direct carrier involvement differentiate BREW from other wireless development provides a path to profit without requiring the developer to independently penetrate the "carrier barrier". integrated distribution and billing features. CONCLUSION Chipset independence.

REFERENCES • • • • • www. Department Of computer Science & Engineering 37 www. where developers from around the world discuss a wide variety of issues related to the BREW For specific information about BREW contact BREW Developer Forums.