Getting Started with BREW
Getting Started with BREW
By: Ray Rischpater
Aug. 20, 2003 01:12 PM
With today's rapid developments in wireless terminal capabilities and increasing pressure to market data-based services, there's a huge market growing for wireless applications that reside on the handset. QUALCOMM's Binary Runtime Environment for Wireless (BREW) platform is an exciting step forward that helps developers create these applications.
Within the BREW platform there's a plethora of Application Programming Interfaces (APIs) that you use with C or C++ to build your application for wireless handsets.
What Is BREW?
The platform provides components that your application can use to perform common operations including:
You can get the necessary tools for developing applications for BREW from QUALCOMM at www.qualcomm.com/brew.
The BREW Distribution System
The BDS is a key reason for the rapid adoption and success of BREW-based applications. By managing the aspects of application distribution and monetization, the BDS provides wireless subscribers with a one-stop shop for application downloads. By integrating with a carrier's billing system, the BDS provides carriers with a secure, convenient mechanism to distribute applications to subscribers. And by providing the delivery channel to developers, it frees you to do what you do best: deliver applications.
Îf you want more details, QUALCOMM has written a white paper about the BDS that's available on their Web site : www.qualcomm.com/brew/about/whitepaper.html.
The Anatomy of an Application
As on most other object-oriented platforms, your applet (BREW's name for applications) itself is a class - specifically, a subclass of the IApplet class. It must implement the interface defined by the IApplet class to process events the system sends in response to system and user interface events. Note, too, that because an application is simply a class, a module can contain more than one applet.
Every class - be it a system class, one of your classes, or an applet - must have a unique class identifier (or class ID). A class ID is a 32-bit integer and is allocated by QUALCOMM as a service to registered developers on the BREW extranet (www.qualcomm.com/brew/extranet).
When obtaining an instance - called an interface, in BREW parlance - to a class, you must use its class ID to request the interface from the system shell, the only interface loaded when your applet first runs. (Exceptions to this are the IShell, IModule, and IDisplay interfaces; your application will receive instances of these interfaces when they're executed.)
You build modules in two ways when developing your applet. During most of your development, you use Microsoft Visual Studio to build dynamically linked libraries (DLLs) that you invoke through the BREW handset simulator running on a Microsoft Windows workstation. Periodically you build your modules using the ARM compiler (available from ARM, Inc., or GNU) and BREW tool chain, resulting in module files (which end in .mod) that you transfer to your handset for on-device testing.
Application Resource and Information Files
In many of your applets, you want to include strings, icons, and dialog boxes. You can include these items in your application using the BREW Resource Editor, which lets you add items to your application. Once you use the BREW Resource Editor to add items to your application, it will create a C header file and a resource file (called a bar file, short for BREW Application Resource file) for your application. You use the constants defined in the header file to access specific resources, much as you would on other platforms such as the Palm Powered platform.
In addition to your applet's module file, your applet or extension must include an MIF file to describe the applet to the handset's runtime. As the handset starts up, it reads each applet's MIF file to determine the applet's name, icons, and class ID. The MIF file also contains additional information, such as the author of the application and a set of flags delineating various kinds of behaviors the application performs (such as file system access or network transactions.) You build MIF files using the BREW MIF Editor, an application included with the free BREW SDK.
Once your application has been created, it will receive events from the system's event pump. Many, but not all, of these events will be familiar to you if you've programmed for other event-driven systems. These familiar events include user key presses, changes in handset state, application launch and termination, and so on. Your application must handle each of these events as needed, using the events to drive application execution.
Two events that may be new to you that your application must handle are events that notify your application when it must suspend operation, freeing as many resources as it can; and when it can resume operation. Typically, your application receives the suspend event when the handset must divert resources elsewhere, such as to handle an incoming voice call or SMS message. Similarly, once the user has finished handling an incoming call or SMS message, your application receives the resume event and can continue operation.
To developer-enable a handset, you must join the BREW developer program and send them a commercially available handset. They'll make the necessary changes to the handset's configuration that lets you use the BREW AppLoader (provided with the software developer kit) to install the module file, resource file, and MIF file on the handset's flash file system.
Writing Your First Application
When the user selects the application from the handset's application manager, the system first obtains the desired class ID of the user's selection and then queries each module's AEEClsCreateInstance function to see if it will create a module that matches the desired class ID. The AEEClsCreateInstance function uses the BREW-supplied AEEApplet_New function to handle the implementation of the interface to the IApplet interface, so all I need to provide is a pointer to the shell instantiating the application, its class ID and module, and a pointer to the application's event handler.
Once the module has been created and initialized, the system begins sending events to the application, starting with the EVT_APP_START event. When the event handler receives this event (or the EVT_APP_RESUME event), it creates a static text control that implements the IStatic component interface to display the text using the shell method, ISHELL_CreateInstance, the usual way to create instances of components. Once it's created, the application sets its text and bounds, redraws it, and updates the screen. Application cleanup - signalled by the EVT_APP_STOP or the EVT_APP_SUSPEND events - simply frees the static control, returning the resources it consumed to the system.
This article has been adapted, with permission from the publisher, from the forthcoming book Software Development for the QUALCOMM BREW Platform by Ray Rischpater, available from APress, LLC.
Reader Feedback: Page 1 of 1
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week