After 1 year of developing 2.1.x and 3.1.x brew devices and after witnessing the upcomming BREW MP software from Qualcom i’ve decided to give my BREW frustration it’s moment of glory.

So of all of ya guys that are not familiar and were brought up to the android\iphone age BREW stands for Binary Runtime Environment for Wireless and it’s been around for years, it was created nd is still maintained by Qualcom inc.
and wither this is the right plaform for you or if it’s a good\bad platform i’ll leave for the reader to decide, for my part i’ll just tell my story

So i worked in the LBS industry (Location Based Services) i ported our shared code to f\different devices and for one year my main goals was to write features and port and work and breath and breed just BREW platform applications.
So what is the BREW SDK for me really ? well i consider it to be C\C++ java, the SDK is pretty vast and cotains many features, from HTTP connections, to location services and even USB access on the device (though i’m not sure from which SDK version) but all in all, you have no real access (like symbian and WM and native code android) to the OS, you apps are first compiled to a binay, linked with the brew libraries using regualr linker (for arm that is) and then it’s changed to .mod file. You then need to get a signature file for your device and application (it’s hard binded to your IMSI) and you are pretty much done. like J2ME jad files BREW got a .mif file which is usually compiled from some form of JSON\XML file that was invented by Qualcom, in the old versions it was pure xml, today in brew MP i don’t know how to call it…
To compile the Brew code you needed to:

1. download the BREW SDK that is suitable for you phone ( in my tie we had 2.1.some lie and 3.1.2 and 3.1.5, these days you have 3.1.5 sp02 and of course the brew MP which i’ll discuss later).
2. download the BREW tools suite which included the resource compiler
3. download brew tools which included the logger and the application apploader which you needed to load apps to the device (no, no OTA here)
4. ah! no that’s not all! you either need to download some form of gcc (minGW or cygwin) or buy realView ARM compiler for 6000$ (you do have a smaller cheaper version for BREW though, to be fair )

yeah that’s it, that’s all you need. Since we were a legit company we had the arm compiler, but wiht only one liecense, thats causing developer to fight who wil have the USB stick next… (MAC based license, on a USB net card). that sucks, i don’t have to tell you… but ce la vie, let’s talk about programing and the devices.

If you check the net you can see all kinf of articles about BREW, how good env it is, how nice it runs and under advantages i’ve even seen was a better API then J2Me and better graphics widgets! so yes guys J2ME API is limited nd lacking, i know and i’m aware of it, the brew API is indeed richer, but not eaiser (maintaining memory, writing mainly in C, reaping your ass off to write in c++), but graphics, who’s the idiot who writes about ice brew graphics what are you from the middle ages ? it’s got terrible graphics , f course you can write your on, just like in J2ME, but it’s ugly non-the less… luckily we had our own UI… working with the off screen bitmap image, clipping lables and headlines and whatever needed to prevent whole screen repaints..
So what am i complaining about, you didn’t hear real issues so far , right ? right, so the issues with brew are like that:

1. no platform or device ID, basically there is something but brew versions used to go our pretty frequently ( i mean FW upgrades) and even after it stopped being frequent , it still happend, and each and every FW upgrade changes the platforms ID spec so if you wanted certain number to identify Samsung R500 or Z6 for example, with hte new FW , you’ll need to update your code, thats not good, unlike J2ME’s microedition.platfom and android’s Build static class you have no real way to know on which device you are in runtime! next we’ll see why we need it…
2. Font’s always an issue… i have no idea why but usually wne you ask from a device to paint a string in a point (x,y) relative to upper left corner of the string you expect that it will be so, but in old J2Me devices, and in most brew devices it has an offest of 1-6 pixels so for example graphics.drawString(10,3,str, TOP|LEFT) you might get the string drawn at (12,4) so you need to increase\decrease the incets for that device.
3. Fonts again, size some devices have nasty fonts sizes, unreadables, so you either ned to : play with it, meaning your medium and lrge will be the same size, OR load different set of fonts (possible in brew) OR load your own ttf fonts (from 3.1.2 i think) and hope it looks good.
4. GPS with network, almost all devices about 2 years ago needed there GPS to be turned off to get proepr network access, that was due to hardware limitations: cheapscates hardware manufacture put only 1 antena for GPS and GSM\CDMA, so they can’t literally share it.so whenever your network implemntation wants to send out request you need to suspend the GPS callbacks.
5. GPS -speaking of which, how the GPs works in brew / well simple you got a function which requests the device for a position you set the GPS configurations (which type – assited or not for eaxmple) , initialize a callback and requests a GPS fix, pretty much like android, right ? wrong it’s one time request. wants more ? in the callback function, you need to request again…
6. GPS modes – ununderstood GPS modes, from most of my years in the LBS industry i’ve seen mostly two times: assited which is a weak GPS with netwok connections that completes it’s missing data for lat\long calculation using a GIS sever, and non-asisted, like BT GPS’es which are strong GPS device that needs only sat. communcation. BREW has 7 GPS modes!!!, yeah yeah, i know, more functions more power, and more confusing too, i have a customer who asked for certain kind of GPs for first fix then another type, i had no problem to implement only i had no idea which modes he was refering to!
7. Threads, in the old version there were no threads, it’s good and bad. luckily all APIs are async so you have no locking cals and no problm runnig anything on the UI thread, since there is no such thread… you can emulate schedulers and threads using repeating timers, it’s no real emulation, but for most part does the trick, non-preemptive though…
8. Logger, the nice feature about brew, at least in those time before adb was the logger you could use DBGPRINTF ike regualr print f and print log message to debug your app since no on device debug exists, but the log strings are limited to 15 charecters or 20 i think, i never had the patiance to actually count… which is of course bad. and you need to use the brew logger to get those logs, the tool is quite comfortable really an saves the logs as well, you you’ll have refference later, but it lcks filtering capabilities and you have to use your own (sed\awk ) tools to do that.
9. the returned value from function should be int and is usualy either success or ome kind of error value, it happend to me more then once that the returned value was a value that is not documented anywhere, that’s not qulacom’s fault but the OEM’s, the part that is qualcom’s fault is the fact that each OEM’s device need to be certified with the brew env, and if they actually do it, it’s not done well.
10. The community for brew is not big and is msotly in korea, india and china, so unlss you can read korean and chinese most of the questions you have will remain unanswered.
11. extending any interface in brew is not hard but also not straitforward, a lot of place to get it wrong and get strange compilation and runtime errors, in adition it’s pretty hard for the IDE to decide whta you need to implement and enforce you to do so, making it eaiser to make a mistake on the way.
12. onError, the most common error i’ve encountered in most brew device is self destruct, when something happens the device doesn’t like it resets itself, very nice, i wonder if qualco didn’t consider over heating the battery on error to destroy the whole device, and good rittens!!!  it can happens to you on null pointers access, it can hppen if you compile code with 3.1.5 sdk while the device works with 3.1.2, it may happend if the application tries to access HTTP while the device (CDMA one) is in a country with no CDMA and network, and go figures why the device crashes, since , GOD FORBID, they’ll print the error causing the crash before it actually crashes…

there are couple of more things i forgot probably, the fact that you can oly appload with that wreched toold brew apploader or QPST, nad if the device uses EFS1 file system you have to understand it, not to mention that the tool is not all that stable and can crash or it’s OEMServer can and leave you with a dick and a non functional apploader…

For the sake of fairness i will  have to say BREW also got it’s up sides… as i said before, no threads make it eaier to programme, not having to ask yourself if you need thread safe component or not. I never had memory issues on BREW, nor did i had problem with my program size, file system access is strait forward, many API’s are relativly easy to use, almost everything is async so the GUIshould respond pretty fast to any action you do, each Interface has many capabilities , the API even includes access to the USB, which is quite cool when you get to think about it, you can write desktop app that will communicate\synchronize with your applet using USB, a thought a head and thumbs up for Qualcom.

In the next article i’ll talk bout the next generation BREW MP and it’s advantages and why it wont disapear in the iphone-android age.

• Previous Entry: When open is not open (hint: not when it’s ajar ;-) )
• Next Entry: Bulding new Android version for ADP2(sapphire).