Blackberry Development

When a company sets out to create a platform, they are essentially making gentleman’s agreement with developers at large that they will try to make their lives as simple as possible to create exciting and useful applications for their platform.  In return, these apps will drive business toward that company’s flagship product.

For Research in Motion, perhaps at one point in their lifecycle, this was the case.  But it is clear that at this point, this is NOT the point.  Therefore, I’d like to encourage EVERY developer (that can afford it… you do what you gotta do, you know?) to avoid designing anything for this problem.  The single most compelling reason to develop for Blackberry is to land a ludicrously large contract developing a specific application for a large company.  That is it.  The platform itself is dated, lacks any real polish underneath that title screen, and lacks any form of real tech support.

The launch of App World (Blackberry’s answer to the iPhone’s App Store) is underpopulated, and filled with uninspired apps.

The reason?  Simple.  Blackberry offers you technicaly support… at the gaudy price of $75/hr.  Unless, of course, you go through your carrier… which doesn’t even make sense if you just want to know some specification for the hardware.

That’s right, if you want to know… oh… let’s say the dot pitch of the display, or the refresh rate of the screen… you (or your mobile carrier) will have to pay $75/hr to get anyone of value on the line.  And even if you do get there, you’ll be told that the first hour is a flat rate 75, even if you don’t talk for that period of time.  And they’ll also provide tech support that include searching their own blackberry forums for the solution.

In short, Blackberry developer support is a farce.  If you can avoid it, don’t develop because you’ll likely cost your company more money than it’s worth, and you’ll have to deal with their bullshit.

As much as I don’t like Apple’s policies, I see the iPhone as the current most likely competitor to knock Blackberry off their high horse.  And boy do they have it coming.

Seeking Gratification – A Glance at Android

For those of you that would like to give Android a spin, it is freely available at this direct link.

This post assumes the reader knows how to create a new android project and is somewhat familiar with the uses of the files automatically created in your Android project.  My personal development environment is Eclipse since it integrates everything nicely, though be warned, you will need a relatively powerful system to run the power hungry Eclipse.  If you have slower systems, be sure to read the Android tutorials on installing the SDK.

If you are like me, your first impressions of the SDK was a bit of a surprise (as with any embedded platform as this).  As someone that just came out of college in more traditional computer engineering/computer science field, we weren’t exposed to the industry standard methods of building GUIs.

Let me explain.  In college, we are used to code like this:

Swing Code

Swing Code, the added action listener simply toggles the text between "Hello, World!" and "Goodbye, World!" using the JLabel's setText() function.

This produces:





However, to accomplish the same thing in Android, it’s a little less obvious.  There are multiple ways of doing it.  You can do it by putting the code into the XML, then acquiring the handle by the XML ID to change the label, or you can do something very similar to the produced swing code.

In this day and age, however, coding GUI elements by hand is tedious, and to make this future proof and as friendly a transition for college students like myself to get into this style of development, we will create this simple application using a GUI builder, then acquire those references for dynamic use in our application.

Let me start off by recommending an amazing application: DroidDraw.  This tool is much better for designing the actual positioning and relationship between your GUI elements (assuming for now that we will only be using standard Android GUI elements).  You simply draw your GUI, then click on “Generate code”.

Using droid draw to make our HelloWorld application in Android!

Using droid draw to make our HelloWorld application in Android!

Next, paste the code it provides into the main.xml file generated by android.  Then, we write the following code in our main activity Java file.

The Android setup.  Note the use of getViewById to grab handles of the GUI elements we want to directly manipulate, and the subsequent similarity with Swing code.

The Android setup. Note the use of getViewById to grab handles of the GUI elements we want to directly manipulate, and the subsequent similarity with Swing code.

I’m not quite sure why Android chose to introduce as it’s first prime example such a complicated tutorial, but hopefully this early look at the corollaries between the Android platform and much more familiar widget toolkits is a help.  The final output is rather obvious, but I’ll post them anyway.

Hi!  Sorry for the misof my widgets, you can blame my cross-eyedness.

Hi! Sorry for the misalignment of my widgets, you can blame my cross-eyedness.


Bye!  Again, blame it on my eyes...

Bye! Again, blame it on my eyes...

Anyway, that’s a little something to whet the appetite as I patiently wait for my G1 to arrive (see my previous post’s screenshot – the picture has not change… sigh).

Hope you enjoyed, and I invite you to discuss and point out any mistakes I’ve made in the comments section!