Verification Errors With Blackberry Applications

If you've worked on applications for the Blackberry and you're unlucky (like me), you may have tried to run your application on the simulator or a device and seen an error message something like this:

"Error starting MyApp: Module 'MyApp' has verification error 2778 at offset 3fce"

It appears that the two numbers (2778 and 3fce, in this case) are not helpful in diagnosing the problem. Basically, you're on your own. And it's going to get ugly.

According to RIM, it's likely that the COD files have been corrupted. Unfortunately, this can happen just by building with the rapc compiler, and optionally signing the app. So, what can you do? Well, I've fought with this a few times and I can at least give you some suggestions to try:

1) If you started by building a JAR and then used the rapc compiler to create COD files, make sure you turn obfuscation off when building the JAR. The rapc compiler will do its own obfuscating and it often has issues if the code is already obfuscated.

2) Comment out dead code. Sometimes the verification errors seem to have something to do with the size of the main code file and the library files. If you comment out some code that never gets called, the file sizes change somewhat, and this often fixes the problem.

3) Remove references to a static instance variable from an inner class. For example, code like the following can sometimes be a problem:

public class MyOuterClass {
static int var;

class MyInnerClass {
  public void doSomething() {
    var = 7;
  }
}
}

There are a few ways you can try to remove these references. E.g., create get/set methods for var in the outer class, or modify your logic so you can pull MyInnerClass out of MyOuterClass.

4) Remove any System.out.* calls. These generally do nothing on the Blackberry, but sometimes cause verification errors.

5) Remove unused import statements.

6) Explicitly specify the access for every function or variable (i.e., make sure every one is specified as public, private, or protected). It's pretty easy to grep your Java code to find the missing access specifications.

Now, it's not clear to me whether these changes actually fix anything. However, you're really just stabbing in the dark with verification errors, so any changes you can think to make may help. My best advice is to use source control and build/test often. You're really just trying to avoid code that makes the compiler unhappy. And it's much easier to do this if 15 lines of code have been checked in since it last worked, as opposed to 1000.

Review of "Little Red Book of Sales Answers"

I'm working my way through a number of different books on programming, UI, and many other topics. Most of these are picked out of Joel Spolsky's list. This is a great list and everyone should try to read everything on it.

Most recently, I finished reading the Little Red Book of Sales Answers by Jeffrey Gitomer. This is a very interesting book. I know nothing about sales and have no interest in it, but still there's a ton of good stuff here. The whole book consists of 100 small questions and answers, so it could not be easier to read. And everyone should!

There are lots of themes in the book, but some of the most important ideas include:

• Communicate! Jeffrey writes newspaper columns, articles, and books. He has his own sales newsletter. He speaks at hundreds of conferences and shows a year. Essentially, if you're in sales, you know Jeffrey. Becoming a figure like this gives him recognitions, makes people trust him, and gives him every employment opportunity imaginable.
• Read! The book recommends that you read a few books each year on positive attitude, sales techniques, etc. In my mind, the subject matter is not really important. I read as much about sales and marketing as I do about programming and software development. And I couldn't care less about sales or marketing. The key here is that Good Books on any topic are worth reading. Of course, if you're dying to become a product manager, you should read some books on product management. But not only product management. Read about as many topics as you can related to your coworkers, customers, managers, etc. Know everything you should know and as much about what everyone around you should know as you can.
• Practice! From public speaking, to negotiating, to cold-calling, this book reminds you that nothing is easy the first time. Like most of the suggestions in the book, this is so obvious. But what do we do about it? Mostly, we avoid the problem with excuses (too busy, low priority, I'm already good enough, etc.) Stop it! Now! I will try to do the same.
• Quit your job! Well, not necessarily. If you don't love it and don't believe in it, do something else. From a sales perspective, Jeffrey argues that if you don't own the product your selling, use it all the time, and love it, you can't sell it. The same goes for pretty much any job. If you're a programmer, for example, and you hate the software you're developing, get out! Otherwise, everyone will suffer. Not just you.
  

The book is not perfect. For one thing, it reminds you of what kind of person gets involved in sales and how annoying they can be. For example, Jeffrey talks about cold calls and how when a customer says "No", it means "Not yet". This is the kind of attitude that forces me to tell a telemarketer four or five times: "I'm not interested in saving money on long distance/health insurance/wireless costs/energy costs!" But this is more of a general complaint against the entire profession, than an attack on the book. As long as there are sales people, there will continue to be a world of people annoyed by their perseverance.

Me on CBC News

Friday, I made a very brief appearance on CBC's "The National". This is a nation-wide news program viewed by over a million people. And what did I do? I stumbled on my one line.

They actually asked me a few questions and this was the only answer I couldn't get out properly. So why did they use this one? Who knows. But, there it is. My 5 seconds of fame consists of me unsuccessfully delivering one simple line.

The piece itself was pretty good. It talked about Google coming to Waterloo, Canada. What, you didn't know Google was in Canada? And you want to work for Google? And you want to work in Canada? Why didn't you say so? Email me at djphilli@gmail.com if you're interested or check out google.com/jobs and look for jobs in Waterloo.

Google is the #1 company to work for in North America (according to Fortune Magazine and myself), so what are you waiting for?