Blackberry Secrets


There’s a lot of fluff content here so feel free to skip to the answers and ignore the rest of the nonsense.

Hi. I’m Cliff, and I own a Blackberry. I don’t actually own a Blackberry, you see that’s the thing. AOL/TimeWarner owns the device but it’s in my posession with all of my favorite music, pics, email, and other customizations. To make matters worse (or better depending on whether you’re one of those who sees the glass as half full or half empty) I am a mobile developer, one who has never owned a cellular telphone of any kind until recently. I’ve never touched JavaME tools before and can’t tell you the difference between 3G EVDO, Edge, or any other cell like buzz word. Well I could now but less than a year ago it was all a mystery to me. Having voluntarily disclosed that bit of personal information I will proceed to tell you how to manage some of the tougher issues with mobile development. Not only am I under-qualified and unexperienced, some call me a nut merely because I have a general liking for RPG and the AS/400 architecture. You see I entered the IT field wielding a 7 1/2 thick keyboard (the kind that clicks loudly on each key press) attached to a 5250 amber screen dumb terminal doing work where fixed column positions in each character of your code meant the difference between a working general ledger and a never ending loop. I feel that if I can connect VBScript through a VB6 COM+ object to RPG code talking JNI to a wrapper class around the POI project spitting out native Excel spreadsheet from a mega computer that doesn’t even have a desktop display then I can speak somewhat intelligently about a technology that I’ve never touched until months prior and warn others against potential pitfalls and work-arounds. I also feel that while I’ve been labeled as a very Non-MS Guy I do know my way around the Wndows OS pretty well and can swing to the fences with the all stars on all but probably the most in depth MS projects out there. (While much content on my site is high exaggeration, all of the above is entirely true.)

But exposing my ignorance and bragging on my abilities is not why I gathered you here today, all twenty of my repeat visitors (15 of which happen to be family members, friends or neighbors). No I summoned you because I’ve made some interesting finds in Blackberry development. There are some pros out there who would read what I’m about to share and laugh. Still I believe the vast majority of novice to developing professionals may find some benefit. With that I’ll begin.

Application Signing
Applying a digital signature to a Java app is hard enough and with Blackberry we have yet another set of tools to do it with. Starting with their proprietary binary format (implied by a “.cod” file extension) Research In Motion entertains us by adding a few twists to the process. If you’ve only dealt in Java and you now attempt to develop for RIM (and why not since it runs Java code right?) you’re bound to make some serious assumptions. I don’t want to call them mistakes because it’s quite common to arrive at certain conclusion given certain circumstances. Lets assume your in a rush which is fair because if you work in IT every job you do is due tomorrow first thing. Let’s also assume you’re confident in our abilities which you have to be to survive in the industry. Now lets do some math.

InARush + Confidence = NoTimeOrDesireToReadOrFullyIngestDocumentation

Now lets assume you’ve taken the approach of using something like Sun’s Wireless Toolkit to sign the app. Again this makes sense because a Blackberry will load Jar files over the air (OTA) and why figure out how to produce that funny looking “.cod” file anyway? Let’s pretend ou got your company to purchase a certificate from Verisign since these things cost money and lets assume that you registered it in your company’s domain name. With me so far? Perfect! Now lets put your abilities to the test and read just enough of the app signing how-to to get through the most basic use case. (Like we’ve never done that before!) Now lets replicate what we read (or thought we read) from the documentation that we glossed over in our above math equation. Let’s run that through a few cycles because nothing in software ever works the first time. (Actually there was this time that I made roughly 26 consecutive edits to some program source, ran the compiler, executed the binary and everything worked like magic but opportunities like that come once a life-time and only after double, triple, and quadruple checking the source.) I’ll code our cycles:

while(engineer.futzesWithSignatureTools() && resultingApp.isStillNotSigned()) {
   resultingApp = engineer.useSlightlyDifferentApproachWithSignatureToolsOn(resultingApp);
}

The above code runs without exiting. Long story amputated, a developer wil eventually breakdown, read the docs, retry everything and possibly still fail.

Enter RIM Tools
RIM offers an emulator that looks and works just like the device (or pretty close). They also give you a development environment (that not nearly good enough to make a hard core guy switch from Eclipse or Idea). Finally they give you the infamous SignatureTool.jar. You won’t know it until after hours of Googling but the SignatureTool.jar is what you’re supposed to use after paying $100 for a RIM certificate. What you also won’t know until you’re another $100 in the hole is that the certificate you pay for can only be installed on a single machine. Of course you got the thing installed on your local box to test it because you haven’t even thought about automating the process yet. Of course you work on a team of say 4-5 other devs that also need to sign once you figure out how to. But that’s not all! RIM, until recently, made it very difficult to run SignatureTool.jar from a tool like Ant because who needs to automate app signing? Isn’t that something that should be handled by the president of the company? Why not register the certificate in his/her name and have the build deliver the binary to the President’s oak table top so that the signature can be scribbled on it with that fancy felt tip hanging at a 45 degree angle in that funny holder?

The Answers
I did a lot of writing but so far nothing solves or explains any solutions so lets wrap up here. You want to move a certificate from a developer mchine to another machine because you installed it before you knew what you were doing. There are three files you need to copy, sigtool.db, sigtool.csk, and sigtool.set. These can be found in the JDE install directory under the bin folder on the machine where the certificate was installed. Simply copy these files to any other machine that needs to do the signing. Secondly you want to perform the signing from your build without dancing with that Swing dialog box. I advise you to download the latest version, 4.3.0 of the JDE (or grab the components package from version 4.2.1) and run the SignatureTool.jar file from the command line passing it the -p switch followed by your certificate password. From Ant it looks like:

   <java fork="yes" jar="${jde.home}/bin/SignatureTool.jar">
   <!-- automate the process -->
      <arg value="-a"/>
   
   <!-- recurse through the following directory looking for stray cod files -->
      <arg value="-r"/>
   
   <!-- close the app regardless of who wins the presidential election -->
      <arg value="-C"/>
   
   <!-- undocument password switch -->
      <arg value="-p"/>   
      <arg value="${my.password}"/>   
   </java>

Finally you want to address the problem where double clicking the .csi file on your build server brings up the Windows “open with” dialog. This problem comes from the fact that you never actually installed a JDK on your build machine, because you don’t need that fancy plugin or nothing. You just want to run a headless build. So why not just copy the JDK folder from your dev box and drop it onto the build server right? Right??? Wrong! When you do that you force the JDE installer to skip over the file association step where it links the .csi extension with a funny looking “javaw -jar SignatureTool.jar” command line. You would never figure this out unless you know something about Windows and could pull up either the association dialog or hack the registry. (This non-MS guy knows how to do both.) Finally, as icing on the cake I’ll leave you with a little tip. Trust me on this one. Always run the Java installer (set a JAVA_HOME env var too if the installer doesn’t) and install Java outside of “C:\Program Files” because you’ll lose a lot less hair on your Java development adventures. It’s been real and until next post… if you really wanna party with me put all of your comments where my eyes can see!

3 thoughts on “Blackberry Secrets

  1. Hey Grover,

    Interesting site. Are you looking more for a social networking app or are you trying to develop something that will be used internally?

  2. Hey Grover,

    Can you put your thoughts on how to extract child .cod files i.e. *-1.cod & *-2.cod form the parent .cod files.
    One way is to make it zip and then extract but i want all the process through ant.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s