Binary Runtime Environment for Wireless
From Free net encyclopedia
BREW is an application development platform created by Qualcomm for mobile phones. It is air-interface independent, i.e. it can support GSM/GPRS, UTMS and CDMA. However, when BREW was first introduced it was solely developed for CDMA handsets. Standing for Binary Runtime Environment for Wireless, it is a software 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 in between application and the wireless device's chip operating system; therefore BREW enables a programmer to develop applications without needing to code for system interface or understand wireless application. It debuted in January 2001.
Even though Qualcomm has demonstrated that BREW applications can run in GSM handsets, due to technological restrictions, BREW applications are currently (as of 2005) intended for use solely on CDMA handsets.
Contents |
Software
For software people, it is a complete set of APIs that enables software development and applications in C, [[C++]] and Java and is supported (platform) by an ASIC. It has a footprint of about 150 K.
BREW application development
Software for the BREW-enabled handsets can be developed in C or C++ using the freely downloadable BREW SDK. The SDK includes a BREW Emulator which can be used for testing during development process. Unlike 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 or authenticated BREW developers have the tools necessary to create a digital signature. Furthermore, developer-signed applications can only execute on test-enabled handsets. Once the application has been developed and internally tested, it must be submitted to Qualcomm for TRUE BREW Testing. After the application passes all tests, it may be offered to a mobile operator (content provider) to be accessible for download 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, 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 cable to any BREW-compatible handset using AppLoader from Qualcomm. A BREW application contains several components which must be present, otherwise it's automatically deleted on reboot. This includes a name.mif file which describes the application, features it uses and permissions requested, a name.mod file which is the actual compiled binary, name.bar which contains string and image resources if required, and a name.sig which is the application digital signature. Applications which do not have, or have an invalid or expired digital signature are automatically deleted on reboot.
Once the application passes testing, it's available for download from the service provider.
Criticism
As of March 2006, the least expensive digital signature for testing costs 400 USD and is limited to a small number of builds [1]. This steep cost of entry tends to exclude hobbyists from developing for phones that use BREW.
Advantages 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 testing costs weed out developers with low budgets, resulting in less market dillution
- 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.
Disadvantages of BREW
Again, this is compared to J2ME
- The entire source file and resources are compressed by default for J2ME. To do the same with BREW, you have to roll your own solution. BREW code can never be compressed (the architecture does not support self-modifying code because of security concerns).
- Profilers for C/C++ are expensive, whereas the J2ME environment comes with a profiler.
Currently, most developers choose to support both, or only J2ME. J2ME offers less cost to get to market (no testing costs). In addition, J2ME is widely used in Europe, while BREW is mostly in the U.S. and Japan. Even in the U.S., the market share for J2ME phones is bigger. One of the big classic advantages of BREW was that Verizon made it easy to purchase applications from the phone, but most J2ME carriers did not. Now most carriers for J2ME phones also offer easy-to-access purchasing portals. So even though J2ME has a lot more undesireable "quirks" than BREW, from a business standpoint it must be supported.