- This blog page is dedicated to Blackberry. You can also find more information at my wiki: http://wiki.cognitiongroup.biz
- While this blog tends to have more anecdotal information, rants, and things you can comiserate about, the wiki focuses more on technical specifications, notes and how-to information.
First, the Good Part
If there’s one thing you can say about Blackberry development … and this goes a long way … is, that the Blackberry technical support desk is very helpful most of the time. The issues I’ve encountered (the ones that I wasn’t able to resolve before the tech support had time to respond) were fixed relatively quickly by the RIM support group. That’s a good record for an outfit that doesn’t charge developers on a per-support case basis. So the RIM support desk has their heart in the right place. If you’re doing RIM development, then you should get comfortable relying on the fine folks in tech support frequently.
Tech support contact (and other useful links):
Phone (North America) 1-877-255-2377
Phone (UK): 0808-100-7466
Phone (Outside the UK): +44-1753-558400
Phone (Worldwide): 1-519-888-6181
e-mail (Very responsive): firstname.lastname@example.org
These support channels are particularly responsive. E-mails for support that are accepted (I’ve not had one rejected yet), are assigned a number, and when you reply, your e-mails are automatically logged into the RIM support system and well tracked by RIM support staff. There’s no lag time between the moment you send an e-mail and the moment the tech support desk associated you e-mail with your case. I discovered this when I called in to follow up on a ticket.
Some other useful links:
Oh, the Misery …
I know … it’s not a very positive title is it? I don’t mean to be so negiative, except that developing for the Blackberry tends to be a complicated affair. Well, it’s more complicated than it needs to be anyway.
If I had to sum up the blackberry JDE, technical docs, and overall development experience, I would say this: it’s all a great example of what happens when very sharp and talented developers at a company like RIM get their work hashed up and stepped on by management and product managers who don’t know how to spec out and manage tech projects. For all the brains and raw development talent at RIM, it’s amazing there wasn’t a revolt by the developers. The problems I’m seeing in Blackberry development tools and technical reference smack of project management problems and feature set myopy. Suggestion: send some of your developers who are tired of coding to an industrial design school so they get enough of an artist cultivated in them to make a development product that works well and is fun to use. Development tools are just another end user product after all. I should WANT to wake up every day looking forward to developing for RIM (I do for Android), but instead I fret all the hours I’m going to be spending looking for technical data and documentation that isn’t there.
I know what you’re going to say at this point. Look in the forums and documentation!
My answer: That’s not the POINT.
For a good IDE, technical information shouldn’t have to be searched out with great effort. Issues in applications should be things I can research immediately. That means everything I need to know to solve problems in the code, emulator or IDE should be readily available in the IDE, if possible. See below.
But rather than just rant and complain, I thought I would dedicate a section of my web page to talk about the kinds of things that might make development go smoother. After all, RIM folks do a great service for the developer community. They help developers get going: provide a complet (albeit rough) development toolkit; RIM offers free technical support for developers; plenty of information through forums; and low cost to entry into the RIM platform as a developer. So, RIM folks deserve some honest feedback.
Besides, since I don’t have access to RIM’s source code to just start making changes, the least I can do is offer some constructive suggestions.
So with that, here’s an ongoing list of things that I hope serves as some constructuve feedback for the folks developing the RIM JDE:
- Be more clear with signing certificate processes or be more forgiving: allow a developer more chances to get their pin correct when registering keys for the first time, and by all means, the signing tool should remind you what the parameters on the PIN number is during the registration process: The website says the PIN must be at least 10 characters/digits – and the Signing Tool should do the same. There should also be a way for a developer to be sent their own PIN should it be forgotten. If I can get my bank to resend a temporary password, RIM should be willing to do the same, I reason.
- The process a developer uses to set up the SignatureTool to use multiple JDE versions should made more clear. Whereas RIM requires multiple JDE version to be used for proper development, and those multiple versions can be installed on the same computer, the process to share signing keys between the JDEs should be made very clear. A wizard guiding the developer through this process would be perfect. Each JDE should be aware of which JDEs are installed, and settings should be automatically shared.
- IDE integration is not very … well … intergrated. specifically, the pop-ups that the emulator generates (e.g. can’t find library so-and-so) tend to get hidden. I shouldn’t even see any notices that say debug files for system libraries can’t be found (because they don’t apply to me, but there they are. But anyway, these messages don’t get the proper focus and come to the front of all the other windows. So, you don’t immediately know why the emulator is stalled. The eclipse plugin doesn’t seem to do much sanity checking (if at all) or automatically generate a .cod file prior to allowing you to attempt running your application in the emulator. The Netbeans setup instructions at http://www.netbeans.org/kb/55/blackberry.html are pretty good. They get me working in Netbeans. However, when the debugger runs, the IDE and the RIM debugger application (emulator and debugger control panel) don’t seem to talk to each other vary well. Breakpoints don’t break execution and bring me back to the Netbeans IDE for a debug session. Netbeans doesn’t seem to know when the debugger exits, and you have to kill the debug process manually. I’d use JDE if it was built around a real IDE like Netbeans. The Blackberry JDE is a nice effort at writing an IDE from scratch, and it does debuggin farily well. I use it once in a while to validate my own builds against the build that the JDE puts together for me. But, it’s not for serious development because it doesn’t handle projects and code reviews the way Netbeans and Eclipse does. Combine Netbeans and JDE, and you’ve got a winner of an IDE for Blackberry.
- Stop making me experiment to learn your product. I love the process of discovery and experimentation. I really do. But it’s not appropriate when you’re trying to get familar with an IDE like JDE. I had to experiment to figure out that if I add file names to the project file, JDE would pick them up and import them into the project. That saves me from having to include files using SHIFT-CLICK in every package directory. I shouldnt’ have had to experiment with that though to figure it out.
- Applications and modules are more complicated to manage than they need be. Installing and uninstalling applications on the RIM platform is
cumbersome and prone to cause issues on the phone. Proper install, deinstall should be enforced: let the command line handle everything. When an appliation is installed in the emulator by simply copying files to the emulator directory, an error should be generated and displayed. IDE plugins should be given a java task to accomplish all of this as well.Sure, javaloader.exe is thert, but it’s difficult to transition from the command line to the UI and Desktop Manager for application management because the behavior between the two modes of package management (command line -vs- IDE) is not consistent.You can copy files to he simulator directory, and there’s the clean.bat utility. But uninstalling applications/modules by just deleting them from the simulator directory isn’t very sanitary, and clean.bat takes way too long.
- Uninstalling apps and modules using the device UI, too, is error prone. There should be a way to completely wipe clean an application. Either all the files in a package are there or not. My IDE complains that it can’t find a class file for an application I already deleted, for example. After wiping out an appliaction, the emulator shouldn’t be looking for the file in the first place.
- Tighter Netbeans integration, please. Netbeans is good. Eclipse is O.K. But Netbeans is better. I use both, but prefer Netbeans.
- Emulate what works WELL, not just what works. While RIM may have set a standard early on for the development of enterprise mobile computing, the dev team could learn a lesson from the folks at Google developing Android (or, is it just that Android folks learn from the RIM experience?).
- Make error messages easier to decrypt and/or find solutions to. That means the IDE or simulator should provide more information rather than less. For example, what on the good green earth is the error in the picture below? How did it happen, how do I fix it, andsoonandsoforth? if I can’t find out the answer to those questions in under 15 seconds, then you haven’t put the right information in the right place.
I know what the error is because I looked, so that’s not the point. You can learn about it at A KNOWLEDGE BASE ARTICLE FOR ERROR CODES. What I’m getting at here is that the extra search shouldn’t be necessary. A more descriptive message in the emulator, some log file output, or a information in help file for the IDE would be more helpful. And by “more information in a help file,” I mean that the only thing I should have to do to read up on this error is search for the text “507” in the IDE’s help search. The error means a .cod file is missing, but it doesn’t say what file, for example. I got the error, BTW when I tried to run a sample application from the Eclipse IDE. Did Eclipse not install the .cod file correctly? Doesn’t the Eclipse plugin do a sanity check on the project before trying to deploy the package and run the emulator. More questions than answers … the problems begin to snowball.
Stop making me read BLOGS and FORUMS. Kind of a weird thing to see in a blog, isn’t it? The idea is this: I should never have to look any other place than the following three places for technical information about Blackberries:
1.) all technical reference information about the blackberry should be placed in the IDE itself (popups, context menus), documentation that can be downloadable as a single .zip file, and in the IDE help file (e.g. Eclipse plugin help file).
2.) whatever information can’t be put into the downloadable documentation, should be put in the knowledge base.
3.) when a blogger updates information or finds something new that isn’t documented, then you should add it to #1, then to #2.
What I’m after here is that all errors and issues that come up from the blackberries related to development should be resolved by 1) clues in the user interface itself, or 2) the documentation. Blogs and forums are ancillary information sources but never should be a replacement for documentation. If something ends up in a blog that is not covered in the documentation, it needs to go into the documentation. I’m tired of hunting through forums, blogs, and sample code for answers to basic problems (such as the error screen above). Document it in the RIGHT place, please. In the meantime I’ve got my wiki, and perhaps someday I’ll write a book. Who knows….
- Put command line references in plain view, and they should always be printed when you invoke a command with no arguments. This is related to the previous bullet point. All command line options to command line tools distributed with the Blackberry JDK should be documented in ONE location, and at a minimum, typing a command line should cause the program to output valid command line options. A simple page with a links to all command line tool references will do for a printed reference. And, the link to this single page should absoutely be at the top of the development reference/support web pages. I’m looking for command line reference to the rapc compiler, but cannot find a simple command line reference anywhere. rapc is very un-informative about it’s command line options when you type the command line.
- The .pdf files for Blackberry development aren’t very helpful. The’re more like documents on the features of the IDE itself and all the “neat” things you can do. I’m not interested. I’m a Blackberry developer and you can assume I’m sold on development. So is my boss, so that information is best left to marketing gloss. What I really need is every facet of the Blackberry’s behavior organized, categorized, and presented in one document, and indexed. A blackberry Encyclopedia, if you will. Break the material into one or more .pdf files if you like, but don’t spread out the information and dilute it between tech manuals that have unrelated names.
- Your developer’s website is hard to digest. As a developer, there are three things I want to see on the developers page:
That’s it. Use those titles, specifically, please. Take a look at any project on Sourceforge or http://apache.org and you’ll see some good examples, although Apache’s website is the better model of the two. Anything in addition to those three items, like the conference, is helpful, but isn’t as important as those three.
If I can’t get to downloads, documentation, and support links without having to read through a bunch of features, gloss, etc… then you’ve just increased the time it takes to get me what I need. Gloss is neat, but it should be the distraction rather than required reading to figure out what on your web page is important to me and not.
- Reorganize the simulator directories. Right now, simulator executables (e.g. 8100.bat) and platform data files (e.g. .cod files) are kept in the same subdirectory by the emulator. That’s really bad form. And, it makes it very difficult to separate what files and programs manipulate the emulator/device itself, and which ones belong in the device’s memory/drive space.
- Fix the JDE, please (and add some features). Problems crop up with the JDE that shouldn’t even be there. For example, the JDE complains about not being able to find a .debug file that it shouldn’t even be looking for. The RIM libraries, for one. But, also I see this behavior whenever the JDE tries to look for a .debug file that has the same name as the directory where my project is stored. Problem is, the directory where my project is stored and the name of the project are slightly different. But JDE doesn’t care. It’s looking for a .debug file with the same name as the project directory name. Oh, brother. And, what’s with not being able to import more than one directory at a time (en-masse) directory import. JDE should provide the option to scan directory tree for project files (.java, .png, etc.)and include the files that are found.