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. The devices are great, but developing for them is not. In this article, I argue that RIM could improve this situation by simply giving developers access to the source code.
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
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
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
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
RIM only provides an example that sets them application-wide (using an
unilluminating mess of factories and cookies).
- Networking is bizarre. There are
(!) 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 (
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
With access to the source, third-party programmers can
produce better tools. There have been some people (
who put together a unit test library for Blackberry programming, but one could
a lot better with source code for the device and simulator.
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.