BlackBerry Web Development - SDK

BlackBerries now have a very cool widget development approach, you can build a web interface, run it through an SDK and it will create the widget or .cod file.

My goal was to learn, to see what it is, what it can do, and decide whether I can use it for some of my projects.

What is it? - I chose to use the command line version of the SDK, because I don’t use Eclipse or Visual Studio (which the SDK can plug into). I had to install some Java DK files as well, you can find references to them in the BlackBerry installation and set up documentation. I didn’t set up a path to the bbwp.exe, I used a relative path to reference it from the widget directories. Worked fine.

What can it do? - I saw the Widget SDK as a tool which would allow me to create cross-platform widgets, where a common core of code could provide key features, and device specific APIs would allow access to device stores such as the call logs, events, phone features, and audio. BlackBerry has an excellent API into those features, and I suspect it will be extended as this approach gains momentum. It’s an excellent balance of proprietary and custom features with a common access method. The two APIs I tested with audio and contact interfaces.

Can I use it? - Yes, but not yet. After I finished, I felt the greatest advantage was that it allows you to create a web application packaged as a widget. Potential issues include ensuring the widget version is updated to stay synchronized with the server, which would not be an issue if the code was delivered directly from a server. It does allow an off-line version. I had a general application in mind, and I think I would wait to see the system mature a little before building.

What I learned

  • It’s Windows based. I may be wrong, but it looks like you need a Microsoft machine for development.
  • It’s new. Everyone is still learning, and I would expect things to change.
  • It works. The process to assemble a widget with the SDK/widget packager does work without any surprises.
  • If it doesn’t work (meaning I made a mistake), it doesn’t work (meaning there aren’t any packaging or run time errors, it just doesn’t work.)
  • The command line packager process was not streamlined. My approach was the following:

    1. Use Windows Explorer to navigate to my widget source code directory
    2. Edit with Notepad
    3. Zip with 7Zip
    4. Navigate to the widget source directory on the command line
    5. Run bbwp.exe using a relative path to the executable
    6. Load the .cod file into the simulator (delete any existing versions first, or reset the simulator)
    7. Test
  • The .jar files referenced must be included in the .zip file prior to packaging. The documentation says to place them under the ext directory, and the ext directory has to be at the same level as the index.html and config.xmlfiles. Be sure to add them into the .zip file
  • A great appreciation for the approach. Although I’m not likely to use it (to me a Smartphone is just a phone, not worthy or in need of nifty software), it is definitely a revolutionary way to allow developers to support multiple devices with a core set of functionality. That said, adoption by other mobile device makers is necessary to make this of value. In all likelihood, there will be some common ground and some custom elements for every device. Innovative package assembly may make it possible to create platform independent applications and widgets. If that is the long range goal, the application architecture must be designed carefully, separating the core functionality from device specific interfaces.
  • Using Eclipse would probably speed the edit/test/revise cycle.
  • If I was a BlackBerry developer, I’d definitely test it out.
  • Audio file delivered through the browser to a BlackBerry are not cached on the device (

    Streamed content is not saved; users cannot replay media unless they download it again.

    This was a side trip.

  • SmartPhones will play an increasingly important role in content and application delivery, web applications should consider providing suitable interfaces for them.