QUALCOMM’s Binary Runtime Environment for Wireless (BREW) is a platform that is ideally suited to creating powerful applications on memory/footprint-constrained devices. One of the ways BREW is able to do this is by working with truly compiled code that has been written in languages such as C and C++. In this article, I will give you a number of tips and things to watch out for?which I have called the Ten Commandments of BREW?that will help you to leverage your existing C/C++ development expertise in the realm of wireless development.
1. You shall have no BREW without QUALCOMM
Most C/C++ developers are used to a development relationship with their platform vendors that looks something like this:
- Buy your tools from the vendor
- Develop your software by yourself (purchasing support as needed)
- Sell your software by yourself
Developing applications for BREW, however, is a much more collaborative process between you and QUALCOMM. The complete process is described at http://www.qualcomm.com/brew/developer/developing/developing.html. The salient points for an experienced C/C++ developer are:
- The BREW SDKTM (software development kit) is freely downloadable from the URL shown above
- In order to develop applications that can be deployed onto real BREW devices, you must become an “authenticated” BREW developer by following the process at http://www.qualcomm.com/brew/developer/become/authentication.html
- At the request of Verizon Wireless and ALLTEL, the two commercial BREW carriers in the U.S., all applications must pass testing before they are made available to the carrier via BREW’s virtual marketplace. More information about this carrier-managed and -controlled testing process is available at: http://www.qualcomm.com/brew/developer/developing/apptesting.html
There are, of course, costs associated both with becoming an authenticated BREW developer and with having your applications TRUE BREW tested. Thankfully, becoming an authenticated BREW developer also gives you access to QUALCOMM’s extensive BREW Developer Extranet, which contains tons of tools and documentation?all geared at helping you succeed.
2. Remember the revenue stream, and be thankful
Once your application has passed the carrier’s required testing, you will encounter another difference to the typical C/C++ application development process. By following the application distribution procedures described at http://www.qualcomm.com/brew/developer/developing/appdistribution.html, you will be able to automatically make your application available for purchase by all of the wireless carriers currently partnering with QUALCOMM for BREW. You create the application price plans (there are different options available) and negotiate directly with the carriers via the BREW Developer Extranet. This certainly beats trying to advertise, sell and license your new application all by yourself!
The BREW Developer Extranet also provides several reports to help you keep track of application usage and payment details once they’ve been accepted by a carrier and become commercially available. You’ll be able to see when various carriers decide to accept your application as well as how often your applications are being used.
3. You shall not exceed your privileges
Most C/C++ developers are used to runtime environments that allow them to do pretty much anything they like. For example, allocating an array of 15 bytes and then storing 100 bytes of information into it?so that 85 of the bytes overrun into unallocated memory?is typically not prevented by most C/C++ runtime environments.
Because BREW is specifically intended for use with handsets?and because most carriers are rightfully paranoid about third-party software adversely impacting their networks?BREW features a sophisticated system of permissions that can severely restrict the actions permitted to your applications. Permissions that can be assigned to your applications at the time of their TRUE BREW testing include:
- File access
- Network access
- Position location
- Telephony features
In addition, only carriers may elect to grant permission to BREW applications to download additional code at runtime.
4. You shall not use unapproved tools
Unlike other C/C++ development platforms, the BREW platform is intended for use with a single development tool?in this case, Microsoft Visual Studio 6. It is not yet compatible with Visual Studio .NET.
In order to develop BREW applications efficiently, Visual Studio 6 must be installed prior to installation of the BREW SDK. This way, the BREW SDK installer can sense that Visual Studio 6 has been installed and configure itself to work as an “Add-In” within the Visual Studio environment.
If you are using Visual Studio .NET or any later release of Visual Studio, the BREW SDK installer will not recognize Visual Studio and will, therefore, not configure itself properly.
5. You shall always create a MIF for your applications
Previous familiarity with C/C++ application creation under Visual Studio will certainly give you a tremendous jump start in the creation of BREW applications. However, as you create your first BREW applications, you will find that the MIF Editor is a new tool of equal importance.
The MIF Editor must be used to create a Module Information File (MIF) for every BREW application you create. The MIF will contain the class ID of your application (which you will get from the Developer Extranet, described above), as well as the permissions your application needs in order to operate correctly, and any external dependencies or licensing restrictions it may have.
6. Honor the interface, and keep its contract
If you’ve done COM development using C++ on the Windows platform, then you are sure to feel right at home within the world of the BREW APIs. The APIs exposed by BREW are 100% interface-based, just like COM. In fact, the base interface within BREW?from which all other BREW interfaces are derived?is very, very similar to the IUnknown interface that serves the same purpose within COM.
Specifically, the IBase interface exposes an AddRef method that is called whenever a client wishes to add a reference to this interface. When that client wishes to release this reference, it is expected to call the Release method on the IBase interface. This makes it identical to the IUnknown interface under COM, with the exception of a single missing method (QueryInterface), which?as you will see below?is also available within the IQueryInterface interface.
7. You shall extend IApplet for all your stand-alone applications
There are exactly two kinds of BREW software. The first of these is known as the Applet. The other is the Extension.
Applets are just like the standard, GUI-based applications that you might run on your desktop computer at home or work?only smaller. Their main requirement is that they must implement the IApplet interface.
The IApplet interface is identical to the IBase interface described above, except for the addition of a single method?HandleEvent. HandleEvent is used by the BREW runtime environment to send events (key presses, for example) into your application so that your code can deal with them.
During TRUE BREW testing, every Applet will be classified as fitting into one of the following categories:
- Games
- Tools
- Personal Information Management (PIM)
- Web Applet
8. You shall extend IQueryInterface for all your BREW Extensions
A fifth category, Hidden, also exists under TRUE BREW testing. This is the category used by BREW Extensions, which are typically derived from the IQueryInterface interface. The IQueryInterface interface features a QueryInterface method that allows any object implementing this interface to return additional interfaces upon request. This means that a client application doesn’t necessarily need to know all the details of all the interfaces implemented by a given object ahead of time in order to use them.
BREW Extensions don’t usually provide user interfaces for themselves. Instead, they provide global functionality that can be used by other BREW applications on the device. For example, a BREW Extension that provides sophisticated mathematical functions might be used by video games to calculate sophisticated movement patterns as well as by financial applications to calculate compound interest.
9. Remember the “smart phone” form factor
The typical BREW device is a kind of smart phone, with some limited Personal Digital Assistant (PDA) functionality. For this reason, you can expect to find functionality within the APIs for accessing most standard telephony features, such as rings, dialing, caller ID, etc. There are also a few primitive APIs for accessing such PDA-style features as address books and databases.
10. You shall have plenty of “bells and whistles”
In addition to APIs for dealing with telephony and PDA functionality, there are loads of cools “bells and whistles” loaded into the BREW SDK that make it distinct within the ranks of mobility platforms. For example, several interfaces are available for Bluetooth-enabling your BREW applications?allowing them to work seamlessly with other Bluetooth-enabled applications running on other, nearby devices.Furthermore, APIs exist for all kinds of sounds (including MP3 and QUALCOMM’s own PureVoice format) and graphics. When you combine this with the speed that BREW’s design for native code provides, you can easily see why some of the best games being created today for mobile devices are being targeted exclusively at BREW.
Conclusion
If you are an experienced C or C++ developer looking to get started in wireless, BREW represents a great potential platform for you?both in terms of its development process and its extensive application programming interfaces (API). Hopefully, these tips will allow you to quickly begin your BREW application development process.
Originally published in the BREW Wireless Resource Center
