QNX’s Reverse Takeover of RIM

Remember that I do not speak for Google. Everything I say here is my own personal opinion and conjecture.

As a resident of Waterloo and a graduate of the University of Waterloo, I know many people in this community who work for Research In Motion (RIM) or who have friends or family members who work for RIM. In some sense, we all have a vested interest in RIM’s continued growth and survival.

Which is why the events of the past 1-2 years have been particularly dismaying. Which, interestingly enough, seems to coincide with RIM’s acquisition of QNX Software Systems. RIM was in trouble before this, but it’s as if the purchase of QNX was the catalyst for RIM’s latest set of woes. Which makes me wonder who is actually running the RIM ship these days…

There have been departures of high-ranking RIM executives and managers in recent months as responsibilities have been shifted to the QNX side of the company. There has been much disarray and confusion among developers about the future of the BlackBerry platform and how they’re supposed to be developing their apps — I’m sorry, but Adobe AIR isn’t what developers want, they want a real SDK (where is it?) with a real platform (not just an operating system) underneath. They want all the features available in BlackBerry OS today with some updates to bring it up to modern times (like say supporting Java 6 — it’s so painful to move back to BlackBerry development after experiencing Android development). They want reasons to spend their time working on BlackBerry apps.

This is pure speculation on my part, but it sure feels like QNX has done a reverse takeover of RIM and is trying to revamp the BlackBerry ecosystem to fits its own view of the world. And it doesn’t look like it’s going to work, does it?

Be the first to comment - What do you think?  Posted by Eric Giguere - January 4, 2012 at 9:55 pm

Categories: Opinions   Tags:

BlackBerry Apps Will Run On The BlackPad

There is a lot of speculation in the press these days over next week’s rumored launch of the BlackPad tablet at the BlackBerry developer conference. There seems to be a lot of hang wringing over the fact that the BlackPad is going to run QNX, an operating system that RIM acquired not that long ago. For example, PC World says:

If the BlackPad is real, then RIM has placed itself in a precarious position of launching a new product and a new operating system without much infrastructure in place. That must change quickly if RIM intends on holding on to its marketshare and creating desire for its latest invention.

But I don’t think it’s as bad as people are making it out to be. Here’s my prediction: BlackBerry apps will run on the BlackPad, even if QNX is used. This is total speculation on my part, but it’s the only thing that makes sense.

Why do I know this would work? Two reasons:

  • Java-based virtual machine (VM): In the earliest BlackBerry models (going back to the Inter@ctive Pager days) everything was written in C++. But when they decided to move from an Intel 386 chip to an ARM chip that caused problems and going forward they wanted to insulate developers from the low-level hardware details. So they slapped a Java layer between the hardware and the apps, using their own custom-built Java-like VM. (It’s not actually a JVM, by the way, it has its own set of bytecodes and you have to transform normal Java bytecode into BlackBerry VM bytecode before an app can be loaded. This is the same programming model that Google adopted for Android, so I guess even the Google guys thought it was a good idea.) BlackBerry apps are written in Java. You can’t write native code for the BlackBerry. Even most of the built-in apps (Phone, Mail, etc.) are themselves written in Java.
  • BlackBerry Built-In: A few years back, RIM launched BlackBerry Built-In, basically a way to run BlackBerry OS (the Java infrastructure + the built-in apps) on other platforms like Windows Mobile.

So, let’s see: developers already write their code in a hardware-neutral manner using Java, and the BlackBerry platform itself has already been ported to other operating systems…. so it’s not a big stretch to see QNX as just another OS target on which to run the platform. Sure, lots of low-level device drivers and so on to write, but once you get the BlackBerry VM running and all the necessary Java APIs implemented you can run BlackBerry apps right on the BlackPad.

Now I could be totally wrong on this! Maybe RIM will introduce a completely new platform based on QNX. Or maybe it’s both: a new OS that combines BlackBerry Built-In so that existing BB apps will run on the new OS. I guess we’ll see next week!


Wondering about BlackBerry Built-In? RIM has pulled most of the information about it from the web, but a few tidbits survive. It was launched in 2005 and listed in the RIM corporate history document. Siemens actually released a phone, the SK65, that had BlackBerry Built-In, ah, built-in. See these reviews of the SK65: engadget, CNET Asia, ZDNet UK.

The ultimate description comes from a Spanish version of a BlackBerry Knowledge Base articles (KB03983) which is no longer available in English but I did find a copy here. To quote:

BlackBerry Built-In technology enables leading manufacturers to incorporate popular BlackBerry® applications into their mobile phones and handheld devices, in addition to supporting push-based BlackBerry wireless services. BlackBerry Built-In devices provide a full suite of applications similar to those found on any BlackBerry Wireless Handheld

Obviously, RIM abandoned the BlackBerry Built-In program. But, as I said above, the fact that they were able to do this in the first place means that getting the BlackBerry app stack (everything necessary to run existing apps) to work on QNX is probably a lot simpler than most people think. Still work, but not impossible…

2 comments - What do you think?  Posted by Eric Giguere - September 23, 2010 at 12:41 am

Categories: Opinions   Tags: , , ,

Windows 7 and the BlackBerry JDE Plug-in for Eclipse

Version 1.1 of the BlackBerry JDE Plug-in for Eclipse runs quite well on Windows 7 as long as you install the right things in the right order:

  1. 32-bit JDK 1.6.x — Start by installing the 32-bit version of JDK 1.6. Even if you’re running the 64-bit version of Windows 7, use the 32-bit version of Java, otherwise things won’t work. (I know, I tried!) For good measure, you might want to define a JAVA_HOME environment variable and put the JDK and JRE bin directories (%JAVA_HOME%\bin and %JAVA_HOME%\jre\bin) into your PATH.
  2. 32-bit Eclipse Classic 3.5.x — Don’t bother with Eclipse 3.6 or higher, they don’t work. (I know, I tried!) Visit the Eclipse downloads page and download the latest 32-bit version of Eclipse 3.5.x. Note: To “install” Eclipse you just extract the contents of the zip file, I like to extract it to C:\ to make it easy (i.e. you end up with C:\Eclipse as your Eclipse installation directory).
  3. BlackBerry JDE Plug-in Version 1.1 — Once you’ve verified that your virgin Eclipse installation works (just run the eclipse.exe application in the root Eclipse folder), download and install the JDE plug-in.

At this point you should be up and running and you can follow the tutorial and other documentation that’s on the JDE Plug-in documentation page. One of the first things you’ll want to do is add the BlackBerry Update Site to the list of Eclipse update sites and then download one of the pre-5.0 BlackBerry SDKs so you can target earlier devices.

Be the first to comment - What do you think?  Posted by Eric Giguere - July 4, 2010 at 9:44 pm

Categories: Tips   Tags: , , ,

Runtime String to Long Conversion For Hashing

BlackBerry programming certainly has its peculiarities, and of them is the way you generate hash keys using a menu item in the Java Development Environment. If you want to persist an object, for example, you’ll need to generate a key to associate with the object in the persistent store. That key is used to retrieve the contents of the object from the persistent store the next time the application starts.

The way you normally generate such a key is to type in a unique string (usually the fully-qualified name of a class in your application) into the JDE text editor, select the string you just typed, right click on the selection, and then choose the Convert ‘yourstringhere‘ to long item from the popup menu:

This key generation method always seemed a bit peculiar to me. What if you wanted to generate a key dynamically at runtime? What if you weren’t using the JDE as your text editor?

Luckily, in BlackBerry API 4.0.2 they exposed the stringHashToLong method in net.rim.device.api.util.StringUtilities that generates the same keys that the JDE does. (The StringUtilities class is underappreciated, I think, and worthy of further discussion in a later post.) Runtime generation of hash keys is trivial with this method, but not a lot of people know about it.

Reference: net.rim.device.api.util.StringUtilities.stringHashToLong

Be the first to comment - What do you think?  Posted by Eric Giguere - May 12, 2010 at 6:33 pm

Categories: Tips   Tags: , , , ,

BlackBerry Object Persistence

The BlackBerry has a simple data persistence model loosely based on Java serialization. You don’t read or write data explicitly, what you do is store it in Java objects and pass those directly to the persistence APIs for storage. It’s very convenient and quite simple to use.

What Can Be Stored?

The object store knows how to store all Java primitives: int, long, etc. In the documentation for the net.rim.device.api.system.PersistentObject class you will also discover that the following classes are implicitly persistable: Boolean, Byte, Character, Hashtable, Integer, Long, Object, Short, String, and Vector. The object store can also store arrays.

Any other class can be made persistable providing it satisfies these conditions:

  • It implements the net.rim.device.api.util.Persistable interface
  • Its instance data (including object references) is itself persistable

The built-in support for persistence of primitives and common classes like String makes it easy to create persistable classes.

Note: Every non-system class that is to be persisted must explicitly implement the Persistable interface, even if a superclass already implements it.

How to Persist Data

A persistable object can be stored using the net.rim.device.system.PersistentStore class by associating it with a unique integer key, which by convention is the 32-bit hash of the fully qualified name of a class in your application. It can be retrieved at any time using that same key. An instance of the net.rim.device.system.PersistentObject class is used as an intermediary. Here’s an example drawn from the API documentation:

 import java.util.*;
 import net.rim.device.api.system.*;
 public class AddressBook
     static Vector addresses;
     static PersistentObject persist;
     static {
         // Hash of "net.rim.sample.AddressBook".
         long KEY =  0xa3b3159378f59a29L;
         persist = PersistentStore.getPersistentObject( KEY );
         addresses = (Vector) persist.getContents();
         if( addresses == null ) {
             addresses = new Vector();
             persist.setContents( addresses );
     void add( Address a ) {
         addresses.addElement( a );

To load persistent data, you first call PersistentStore.getPersistentObject to obtain the unique instance of PersistentObject associated with the key. The actual data stored by the object is retrieved using getContents. If there is no data, a call to setContents is required to make the linkage. Anytime you change the data in the application, call commit to persist the changes into the store — the data is not saved until you commit it.

Key Generation

The contents of the persistent store are global to the device, so any application can access any other application’s data. There are important security considerations with this, of course, and if this is an issue you should definitely look into how to secure your data when using the persistent store. It’s rather complicated, I’m afraid.

We’re not going to go down that path, though, and instead we’ll assume it’s OK to store unencrypted data in the persistent store.

The main thing is to keep applications from writing over each other’s data. As I mentioned previously, there’s a convention for generating the key used to store the persistent data. Using the BlackBerry JDE (Java Development Environment), type the name of a fully-qualified class into the text editor. Select that name, then right click on it and choose the “Convert …. to long” option in the popup menu. The string will be hashed and converted into a hexadecimal value. It doesn’t guarantee uniqueness, but the chances are pretty good that there will no collisions if you start with a class name that is unique to your own application.

Automatically Deleting Persisted Data

When your application is uninstalled by the user, all persistent data saved by the application is automatically deleted as long as the persistent data references one or more of you application’s classes. A vector of strings would not be deleted, however, because the vector and the strings are system classes. If you want to use a Vector or Hashtable to store your data, the easiest way to ensure that the data is deleted on deinstallation is to create a persistable subclass of Vector/Hashtable within the Java package used by your application.

Class Changes

What if you change the layout of a class that’s been persisted? Unless you’re very careful, the data will be lost. You can add or remove methods and add or remove static data, but adding, removing or reordering instance data will land you in trouble.

The best way to avoid problems is to not change any of your persistable classes. Either ensure that your classes are extensible by design or create separate classes and provide a way to load data stored in the old format (the previous class) into the new format (the new class).

For More Information

To learn more about BlackBerry object persistence, read the API documentation for the following classes:

In the next post I’ll show you a simple class I use for persisting application data.

Be the first to comment - What do you think?  Posted by Eric Giguere - May 8, 2010 at 12:39 pm

Categories: Tutorials   Tags: , , ,

Java Serialization

Java 1.1 introduced the concept of serialization and deserialization to automatically store and retrieve arbitrary sets of Java objects. See The Wonders of Java Serialization for a good introduction. Essentially, serialization uses the Java reflection APIs to figure out the data members that are inside a class and then grabs their current values and saves them to a stream. Very cool technology and also very complex — there’s a lot of overhead involved in serializing and deserializing objects.

Be the first to comment - What do you think?  Posted by Eric Giguere - May 6, 2010 at 3:53 pm

Categories: Glossary   Tags: ,

Switch to our mobile site