Skip to main content

Where is the source?

Posted by cayhorstmann on December 1, 2008 at 7:55 AM PST

This semester, my software engineering class is working on a project to
bring the San Jose Cinequest film festival catalog to the Blackberry. RIM has
generously donated us some devices.

Being a keyboard person and not very touchy-feely, I like the devices much
better than the iPhone. Developing for them is another story. I am href="http://www.berryreview.com/2008/01/14/rant-blackberry-platform-not-developer-friendly/">not
href="http://rnickel.blogspot.com/2008/01/my-issues-with-blackberry-i-love-my.html">the
only href="http://www.blackberryforums.com/developer-forum/112829-tell-rim-what-you-would-like-change.html#post799074">one
who has gripes about that.

  • The development environment is a quaint, homegrown Windows program.
  • RIM lives in the world of points and clicks. There is no provision for
    automatic builds and tests. I am thankful for the third-party href="http://bb-ant-tools.sourceforge.net/">bb-ant-tools and Dave
    Mitchell who href="http://blog.lightvoid.net/2008/04/28/automated-blackberry-sign-tool-mac-linux-windows/">figured
    out how to get the signing tool to work outside Windows. (The tool
    looks for signature files with the relative path
    ..\bin\sigtool.csk, with backslashes in the path
    name—how lame is that?)
  • The API documentation is less than stellar. Check out the documentation
    of href="http://www.blackberry.com/developers/docs/4.2api/net/rim/device/api/ui/component/RichTextField.html">RichTextField.
    If you stare hard enough at it, you can probably figure out how to set up
    the offsets, attributes, and fonts. But what are those cookies? And how do
    you set colors?
  • Many methods have this ominous comment:
    Framework: This element may be called by the
    underlying framework. Members that are invoked by the framework may not
    behave exactly as documented.” Huh?
  • Some things seem just impossibly hard. For example, I cannot figure out
    how to set patterns for “active regions” (those items that you
    can quickly select with the nifty trackball) in a single href="http://www.blackberry.com/developers/docs/4.2api/net/rim/device/api/ui/component/ActiveRichTextField.html">ActiveRichTextField.
    RIM only provides an example that sets them application-wide (using an
    unilluminating mess of factories and cookies).
  • Networking is bizarre. There are href="http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/348583/800451/800563/What_Is_-_Different_ways_to_make_an_HTTP_or_socket_connection.html?nodeid=826935&vernum=0">four
    (!) different networks to which you may want to connect, and it is up
    to you, dear developer, to code your way through the selection process.
  • There are two (!) separate developer forum sites ( href="http://www.blackberry.com/developers/forum/index.jsp">here and href="http://supportforums.blackberry.com/rim/board?board.id=java_dev">here),
    which are both sad.

Ok, why am I surprised? It's not that the Windows API is a walk in the park,
and you can't expect RIM to have the same developer resources as Microsoft. But
I haven't programmed with Windows for many years. With everything that I have
done recently, I had access to source code, and there was a
public bug list.

Publicly available source need not mean open source. Long before Sun saw the
wisdom of open-sourcing Java, most of the library source was included with the
JDK (and it was easy to get the rest through a free “research
license”). And the bug parade has been there since JDK 1.0. There have
been many times where I scratched my head about some weird behavior, and I
could either read the source or find a bug report. Or, if I wasn't able to do
that, someone else was, and that someone would post intelligent answers on a
forum.

With access to the source, third-party programmers can
produce better tools. There have been some people ( href="http://www.jonathanhfisher.co.uk/b2/?p=8">here and href="http://www.developer.com/ws/other/article.php/10949_3760891_1">here)
who put together a unit test library for Blackberry programming, but one could
a lot better with source code for the device and simulator.

use-the-source.jpeg It is just
crazy how unproductive it is not to have the source. Come on, RIM, and everyone
else out there who still locks their source away from public view. If you had
super-great APIs and dev tools, maybe there would be a competitive advantage to that
secrecy. But otherwise, what's the point? You'll have happier, smarter, and
more productive developers if you let them use the source.

Comments

Why not an AJAX based web application? BlackBerry Bold and Storm now support AJAX, the web browser is far of perfect but is capable. You can use ItsNat, this AJAX web framework is the first with explicit support of BlackBerry Bold and Storm and fixes some annoying bugs of the BB browser. http://www.itsnat.org

+1

+1 ^ n

Well said. I have similar experience. It is pailful.