Basics of BREW Development

Exercise Your Mind

Basics of BREW Development

Not very many people know that much about BREW (at least in my experience).  It’s a relatively old framework developed by Qualcomm to allow developers to create applications on mobile devices that use their chipsets.

It’s similar to Apple’s iOS SDK and Google’s Android SDK in that it gives you low level access to hardware, GPS information, etc.  Although it’s capable of presenting graphics, it isn’t as straight forward or as powerful as iOS and Android.

It’s cumbersome, difficult to understand, and difficult to develop for. I know that there are solutions out there that present the developer with more of a user base as well as a more pleasant experience, so why use it? My main reason is because Qualcomm produces some of the best SoC’s on the market for small embedded CDMA/GPS devices.  They sell their chipsets for next to nothing (of course expecting a nice royalty from all devices you sell).  I’m talking more about embedded wireless solutions rather than mobile phones.  They have a proven track record of a stable platform as well as excellent GPS support, using their GPSone technology.

In order to produce a Shell-based application (or module in brew-speak), you have to have the following three parts:

  • AEEClsCreateInstance – this is the entry point into the program
  • An event handler – this is called automatically and handles events 🙂
  • A memory cleanup handler – this is called automatically when the module closes

AEEClsCreateInstance

Now, an explanation.

Modules have this notion of class id’s. A class id uniquely identifies a module and it’s author for when you get it signed (since all brew apps need to be signed). So, the first thing we do is check to see if the class id that the module thinks is starting is the actually class id of the module. If it isn’t, then the module will likely crash.

Next, we call AEEApplet_New. Let’s break down what we’re passing into this function:

The first thing it requires passed into it is a struct describing the module and any global variables. This struct is like a reference to the application, defining its footprint.

We’ve already discussed the class id, so next we’ll look at the shell interface. The shell interface is how the application interacts with the low level brew api calls. In order to use any of the api’s interfaces, you usually have to pass in the shell interface.

Next is the module and applet interface . These are just a reference to the current module/applets instance.

Now, comes the SampleApp_HandleEvent function. This is one of the most important pieces. It is how anything in your application gets handled. BREW is strictly an event based SDK, so no while(true) loops or polling (in the classical sense). This is just a pointer to the actual function, and will be called when any event gets thrown from the lower layer of the AMSS.

And finally, the SampleApp_FreeAppData function. This is a function which will free all resources that you’ve gathered up throughout the program. Since BREW is natively C, there is no garbage collection and advanced memory management. You have to remove all references when you’re through with them.

SampleApp_HandleEvent

This is the event handler. You should probably note that the only event that an application must handle is the EVT_APP_START event. If the application doesn’t return true to this event, then BREW will close the applet.

You can use this function to handle any event that comes into your application, including any events you throw yourself.

SampleApp_FreeAppData

The last piece of the puzzle is cleaning up your mess.

Conclusion

That’s pretty much it. If you have these three parts, then you have the programming aspect completed. Of course, there are other pieces to go over such as, MIF files and their function, BID files, compilation, and all of the other fun aspects of BREW. Once you get these down, you’ll find that BREW really is a good platform to develop embedded applications on. Not necessarily a good candidate for full blown user experience applications, but definitely better than your typical embedded application.

*Qualcomm now has an alternative interface to IShell called IEnv. The methodology for creating an application is different and this post only covers IShell.

 

One Response

  1. Jess says:

    I enjoyed your article. I am ready to begin programming in BREW! 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *