Digital Meanderings
Meanderings of a coder

In a previous post (BlackBerry Code Signing Help), I ran into problems signing my API Keys (.CSI files).  Also in that post, I had trouble Requesting Signatures for my application.  Both problems are now resolved and I was able to successy install my latest project onto my BlackBerry Storm.  (My tweet-of-joy)

Instead of simply making this a “yippee” post, I’m going to provide details on how to sign your API keys and then how to request signatures for your application.  I realize that BlackBerry provides instructions but they don’t seem too clear, at least they don’t to me.

Request Java Code Signing Keys

RIM requires that a developer register with them before he is allowed to access certain “sensitive” APIs.  These APIs fall under three categories: Runtime APIs, BlackBerry Application APIs, and BlackBerry Cryptography APIs.

Registration is $20 and you can register online using the “BlackBerry Code Signing Keys Order Form.”  For more details as to why RIM requires registration and for what specific APIs are controlled, visit the “Java Code Signing Keys” page.

Registering Your Keys with The Signing Authority

Once you have registered for your code signing keys, RIM will send you three files: a “client-RCR-#####.cod,” “client-RRT-#####.cod,” and a “client-RBB-#####.cod.” Each file will be sent in a different email.  You can then follow the instructions in the “BlackBerry Signature Tool Developer Guide” (a PDF download).

This is where I ran into my first problem - when I double-clicked a .COD file, Windows did not know which application to open the file with.  Please refer to my “BlackBerry Code Signing Help” article for instructions on how to resolve this issue.

Once you have successfully registered your keys with the signing authority two files will be generated - a “sigtool.db” and a “sigtool.csk.”  These files will be placed in the same location as the “SignatureTool.jar” file.

If you have the BlackBerry JDE Plug-In for Eclipse and the BlackBerry JDE installed be very careful as the “sigtool.XXX” files may have been placed where you don’t expect! In my case, they were placed in the directory of the stand-alone JDE therefore the Eclipse plug-in couldn’t find them.

Signing Your Application Using the BlackBerry JDE Plug-In for Eclipse

To sign your application first make build it by going to Project >> Build Active BlackBerry Configuration.  Next, go to BlackBerry >> Request Signatures this will bring up the “Signature Tool” window.

The Signature Tool window will contain multiple rows of data but you really care about the rows with a “Status” of “Not Registered” and a “Category” of “Required.”  If the text in the “Status” field is red it means that the key mentioned in the “SignerID” column is missing or that the key hasn’t been registered.  If the text in the “Status” field is navy blue it means that the key mentioned in the “SignerID” column exists and has been registered but the application has been signed with that key.

To sign your application (represented by a .COD file) click the “Request” button at the bottom of the “Signature Tool” window.  You will then be prompted for your Private Key.  Note that the Private Key is different from the Registration PIN you supplied to RIM.

Once your application is signed the “Status” fields will read “Signed” and they will be green in color.  You are now ready to deploy your application to a real BlackBerry.

Remember that each time you build your application a new COD file is generated and it will need to be signed again before the application can be deployed to a BlackBerry device.

I hope this article provides you some guidance as you get started in developing BlackBerry applications.  If you have any comments please feel free to email me or post a comment.

I ran into a little trouble with BlackBerry’s code signing scheme.  The root problem was that Windows didn’t know what program to use when opening a .CSI file.  I feel this is a problem with the BlackBerry JDE Plug-In for Eclipse installation, but I still needed a resolution.  The tech support team at RIM referred me to a knowledge base article which pointed me in the right direction.  Since I had a compatible Sun JDK installed, and I didn’t want to re-install RIM’s tools again, I opted for the command line method.  Since you have to sign three different keys, I created a batch file to make things easier.

The batch file I created is below.  Please look at the simple code since you may have to change some of the paths to make them appropriate for your system.  Once you create the file, place it in the same directories as your .CSI files and then you’ll be able to simply drag-and-drop the .CSI file “into” the batch file.  You’ll then be prompted for all the information RIM needs to register your keys.

javaw -jar “C:\Program Files\Research In Motion\BlackBerry JDE 4.7.0\bin\signaturetool.jar” %1
pause

Now that your CSI files are signed, you need to register your application.  In Eclipse, you go to Eclipse >> Request Signatures.  Then you select each record in the table with a status of “Not Registered” and click the “Request” button.  This is where I, again, run into trouble.  Check back later, hopefully tomorrow, when I write up instructions on registering your application.

I’ve embarked on a new project that involves writing software for the Blackberry.  So far it has been a maze of encryption keys, development environments, simulators and lots of mis-steps.  In the coming months I plan on writing a few posts on my experiences but, for now, I plan on focusing on one of the things that has been causing me the most pain - The Blackberry JDE (Java Development Environment) plug-in for Eclipse.

In the past I’ve used Eclipse extensively.  While at Lodgenet, it was my main IDE.  So I’ve gotten familiar with the environment and it’s plug-in potential.  Although I consider myself experienced, I’m definitely not an expert when it comes to Eclipse which could be the main source of my agony.

Overall the JDE plug-in is very nice.  It allows you to seamlessy develop and test your Blackberry application against a wide variety of simulators.  (If you’ve ever checked out the original Java Development Environment from RIM, you realize how much nicer Eclipse is.)  The problem I ran into is this - I had all of the JDE Component Packages installed yet I couldn’t see the simulator for the Blackberry Storm.  After some back-and-forth with RIM’s Technical Support proved to be worthless, I returned to a lot of digging on Google.  Thankfully I came across this thread in their support forums.  It had the answer I was looking for:

You can then select the comoponent pack to use  from Window->Preferences->BlackBerry JDE->Installed Components.  This will let you use the simulators available for the component pack you choose.

That one simple paragraph saved the day.  I can now test applications for my Storm, and my friends’ Blackberries (Friends, if you’re reading this you’ll be getting an email soon asking you to help me alpha/beta test this software.)

To help other people who are as dense as I am, or those who just want to see what I’m talking about in action, below are some instructions and screen shots that show the problem I had.  I will also show you how to configure Eclipse to make your development go a little more smoothly.

Choosing Your Component Package

This is where I went wrong - I didn’t know this could be done!  Simply go to Window >> Preferences and you’ll see a dialog like the one below.  In the “Choose one of Installed Components” menu, you’ll see all of the JDE Component Packages that you have installed.  Each component package is used for testing a different version of the RIM’s Java API and for running different phone simulators.  You must do some research on which component package is appropriate for your situation, see RIM’s KB article:  What Is - Appropriate version of the Blackberry JDE.

Note - I think it’s safe to assume that if the Component Package you select doesn’t include all of the devices you’d like to support, you’ll need to create a separate release.  There may be a work-around or “Compatibility Setting” to make things easier, but I haven’t found (nor have I really researched) one.

Creating a Run Configuration

If you’re familiar with Eclipse, Run Configurations are nothing new.  But, I include some instructions here just for completeness.

To create a new Run Configuration, go to Run >> Run Configurations and you’ll be presented with the dialog below.  Using the tree on the left of the dialog, select “Blackberry Simulator” then click the “New Launch Configuration” button.  Give the configuration a meaningful name (Example: “BB Pearl 8130″) and select the “Simulator” tab.  On this tab you’ll see a “Profile” menu.  In that menu are all of the devices that are supported by the Component Package you selected previously.  To make this configuration match the name above select “8130-JDE.”  Now, click the “Apply” button and that will save your configuration.

I recommend that you create a Run Configuration for each device you want to test.  Alternatively, you can create a configuration for each Component Package you have installed.

Using Run Configurations

Using the configurations you create is simple - Open the Run Configurations dialog, select the appropriate configuration and then click the “Run” button.  Once you use a configuration once, it will be added to the list of configurations under the “Run” button (the one that is located on the main IDE screen). One thing to remember is that you’ll get odd errors if you use a run configuration that includes a device that isn’t supported by the Component Package that you’ve selected.  Therefore, be sure to keep in your mind which device you’re using and which Component Package you have selected.

Often times I find the debugger to onerous for viewing DAOs. They usually contain lots, and lots of attributes and viewing those attributes is tedious, at least in my opinion. I prefer looking at them as text output. With text I can quickly scan through them or copy them or do any number of other things. With the debugger, their values reside strictly in the debugger.

My first reaction has been to create a toString method. This works rather well but it too is tedious. So I’ve created a toString method that uses reflection to create the output. The code for this method is located at the bottom of this post.

Some things to note:

• This code has been created for my own use. Therefore you won’t have some of the objects I reference.
• This code is free for all uses. If you’d like to use it commercially or for your own pet projects feel free to do so. Although I wouldn’t mind a mention (or a link) in the Javadoc or on the application’s web page if you see fit to do so.
• This code is by no means feature complete. For example, I imagine it could be recursive so that when an object is encountered, this method is called instead of the Object’s toString method.
• I also notice that my escape characters are no longer escaped. This means that you’ll have to add your own backslashes.
• This code uses StringBuffer when StringBuilder would be more appropriate.  I used StringBuffer because of constraints that were put on me when I originally developed it. (If you’re interested in the differences between these two check out: http://forum.java.sun.com/thread.jspa?threadID=652378)

The Code

    public static String toString(Object a_oToConvert)
    {

         if(a_oToConvert == null)
         {
              return "Object is null";
         }

         StringBuffer sb = new StringBuffer();

         sb.append("n");

         sb.append("t" + Util.DASHES + "n");
         sb.append("t" + a_oToConvert.getClass().getName() + "n");
         sb.append("t" + Util.DASHES + "n");

         Class cls = a_oToConvert.getClass();

         Field[] arrFields = cls.getDeclaredFields();

         for(int idxField = 0; idxField < arrFields.length; idxField++)
         {

              Field fldCurrent = arrFields[idxField];

              String sName = fldCurrent.getName();

              Object oVal = new String("---");

              char[] arrChars = sName.toCharArray();
              char[] arrMod = new char[arrChars.length];

              for(int x = 3; x < arrChars.length; x++)
              {
            	  arrMod[x - 3] = arrChars[x];
              }

              String sFirstChar = new String("" + arrMod[0]);
              arrMod[0] = sFirstChar.toUpperCase().toCharArray()[0];

              String sGetMethod = "get" + new String(arrMod).trim();

              try
              {
                   Method methGet = cls.getMethod(sGetMethod, null);

                   if(methGet != null)
                   {
                        oVal = methGet.invoke(a_oToConvert, null);
                   }

                   if(oVal == null)
                   {
                        oVal = new String("Value is null");
                   }
                   else
                   {
                        if(oVal instanceof List)
                        {
                             oVal = "List Size: " + ((List)oVal).size();
                        }
                   }

              }
              catch(NoSuchMethodException nme)
              {
                   oVal = "No such getter - " + sGetMethod + "()";
              }
              catch(IllegalAccessException iae)
              {
                   oVal = "Not public - " + sGetMethod + "()";
              }
              catch(InvocationTargetException ite)
              {
                   oVal = "ITE" + ite.getLocalizedMessage();
              }

              sb.append("t" + Util.beautify(sName, oVal.toString()) + "n");

         }

         sb.append("t" + Util.DASHES);

         return sb.toString();

    }

While working on a side project of mine, I decided that I wanted to allow users to authenticate themselves using OpenId. Being a Java programmer, who is reluctant to re-invent the wheel, I immediately searched Google in hopes that someone had already created a Java library I could use. After a few moments I came across OpenId4Java. These guys created a wonderful product which made implementation a breeze. It’s also worth noting that the support is pretty amazing as well.

After playing around with the code a little bit, I noticed that the sample code didn’t play too well with my Struts application. So I wrapped their code into my own class OpenIdAuthenticator. This class simply wraps the logic from the sample code to make it compatible with Struts.

Feel free to use the class for any purpose - commercial, private, etc. If you so desire, please give me some credit somewhere in the Javadoc.

I imagine many of us use multiple Workspaces during the course of our daily lives. If you’re like me, switching back and forth between workspaces can cause trouble. i.e. Changing code in one workspace when you think you’re in another. You setup your machine to run multiple versions of Eclipse but that takes up Taskbar space and resources. With the tip below you can be privy to all the workspace you’re currently working in without having multiple versions of Eclipse.

Right click on your Eclipse shortcut and append the following text to the “Target” field: “-showlocation [workspaceName].” Restart Eclipse and you’re ready to roll!