BREW stands for Binary Runtime Environment for Wireless. As the term ‘Binary Runtime’ suggests, BREW runs on top of hardware platform and can be ported to different hardware platforms.

BREW Application environment supports an event driven architecture similar to Microsoft Windows, Macintosh and other operating systems. There are two types of applications which can be created on BREW. One is Applet and the other is Extension.

An Applet is a GUI application having a user interface and reusable code enclosed in one or more Classes.

An Extension is a reusable code module written by OEMs and third party software vendors to include additional functionalities in the handsets. Some examples for extensions are Java Virtual Machine, Game engines etc. Extensions can be loaded or unloaded on needed basis.

To get into some details, I can discuss the following concepts.

Each BREW application is represented by a single Module object and one or more applets and classes. Each Applet or Class must have a unique 32 bit identifier known as a Class ID. Dummy Class Ids can be used during development process. Unique Class IDs have to be inserted before the application is tested in the BREW handset.

Each BREW application is associated with a corresponding Module Information File (MIF). The Module Information File contains vital information about a BREW application like

• Supported classes
• Supported applets
• Applet details like title, icon etc
• Class IDs for each of application’s applets and classes
• Classes exported for use by other applications

This article should give a reasonable insight into BREW platform and the main concepts involved in it.