3 problems with the Blackberry SDK

DZone 's Guide to

3 problems with the Blackberry SDK

· ·
Free Resource

I like working with mobile device and recently I decided to try out what Blackberry development experience is compared to Windows Phone. I was expecting a well-managed and established development platform, because let's face it - Blackberry was on the market for quite a while. Having extensive experience working with Windows Phone, I had my expectations as to what should be included in the package for efficient development and testing. That being said, I was a bit disappointed to see that the situation was nowhere close to being good. I figured that there are three main problems with the SDK that should be addressed by the developers at BlackBerry - this is my own opinion from my own experience.

1. Plugin != IDE

So the first step is the installation. Should be easy and straightforward, right? Not so much. I registered as a BlackBerry developer and the first thing that I was expecting to download was the BlackBerry SDK plugin for Eclipse. A plugin that actually weights 200+ MB, but alright - I never worked with it, so maybe there is an entire new library block out there. I should mention that BlackBerry development revolves around Java, and I expected whatever is about to be downloaded is going to be integrated with my existing IDE installation.

Nope. Instead, it downloaded an entire new Eclipse installer, that was specifically redesigned for BlackBerry development. Why do I have to do that? And why call it a plugin? 

2. BlackBerry SDK is very raw

Compared to Windows Phone, BlackBerry SDK might have more endpoints accessing the lower-level APIs of the OS, but given the capabilities, it is extremely raw because of the general user interactivity features exposed through it. A lot of controls seem to be completely out of line with the general UI and layout arrangement seems to have a lot of redundant components, like the vertical and horizontal managers, that can easily be replaced by simple control-based properties. Also, a lot of default system controls are lacing basic properties that would make their usage more intuitive (e.g. the separation of labels and choosers in a single block).

3. Glitchy emulator

Half of the times I tried to launch the applications from the IDE, the emulator would crash without any apparent reason - when the application is restarted, it works just like it should, so it shouldn't be the app that is causing the problems. The general performance is bearable and is decent for testing purposes (although I would still recommend having an actual device at hand), however the debugging is again counter-intutitive and you have to jump through quite a few loops to get correct data back from the virtualized application.

All that being said, the general development process is very similar to Android with some different concepts (e.g. no direct representation of intents). It takes a while to get used to it, but I was able to write a full-sized application from scratch in a day, learning time included.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}