BlackBerry API Hidden Gems (Part One)

Java Development

Every time I think I know everything, I am always proven wrong. For example, I used to think I knew everything about BlackBerry® APIs but as I continue developing software I am still finding new, cool classes and methods that make my life easier. I call them “hidden gems” since they are often found by one stumbling across them, but when found are of great use. In this post I will highlight some of my favourite gems, which I hope will make your life as a developer easier too. So let’s dive in.

Weak References

For the longest time I had heard the term “weak references” but never really knew what they were. Once I finally learned, I started to use them all the time to be more efficient and avoid memory leaks. Indeed, weak references are not BlackBerry specific, but are defined right in the CLDC specification in the class java.lang.ref.WeakReference.

So what is a “weak reference” anyways? The behaviour of a weak reference when contrasted with the normal “strong” reference pertains to making an object a candidate for garbage collection. A weak reference gives you the ability to access an object but also makes it available to the garbage collector. So why would this be useful? I find that there are often circumstances when you only care about an object if someone else does. Holding a weak reference to an object is one way of determining if anyone else cares about it, based on the assumption that anyone who cares about it will hold a strong reference to it. Once nobody cares about the object (other than me) it will be garbage collected. This is the opposite of holding a strong reference to the object, as doing so would prevent the object from being garbage collected, wasting precious memory.

One excellent use case for weak references is holding a reference to an application object. In general, you only need to reference an application object while the application it represents is alive; once the application exits you no longer need the reference. By holding a strong reference to the application object, the garbage collector will be prevented from freeing the object’s memory even after the application exits, along with the massive number of objects that it recursively references. Instead, holding a weak reference to the application object allows it to be garbage collected when the application exits.

Below is an example of how a weak reference to an application object can be used in a memory-efficient manner to determine if an application is still alive.

import net.rim.device.api.system.Application;
import java.lang.ref.WeakReference;

public class ApplicationLifeMonitor {

private WeakReference _appRef;

public ApplicationLifeMonitor() {
Application app = Application.getApplication();
_appRef = new WeakReference(app);
}

public boolean isAlive() {
Application app = (Application) _appRef.get();
return (app != null && app.isAlive());
}
}

UIDGenerator

The UIDGenerator class does exactly what its name implies: generates unique IDs. Its class javadocs defines it as “a utility class to generate 32-bit unique IDs that can be used for synchronization or any other purpose.” Here’s an example to show how it could be used:

public class Person {

private int _id;
private String _name;

public Person(String name) {
this._id = UIDGenerator.getUID();
this._name = name;
}

public int getId() {
return this._id;
}

public String getName() {
return this._name;
}
}

IOUtilities.streamToBytes()

Have you ever written code like this to dump the bytes from an InputStream into a byte[] array?

public static byte[] getBytes(InputStream in)
throws IOException {
ByteArrayOutputStream out = new ByteArrayOutputStream();
byte[] buffer = new byte[2048];
int readCount = in.read(buffer);
while (readCount >= 0) {
out.write(buffer, 0, readCount);
readCount = in.read(buffer);
}
return out.toByteArray();
}

Now you can do it in one line:

public static byte[] getBytes(InputStream in)
throws IOException {
return net.rim.device.api.io.IOUtilities.streamToBytes(in);
}

Impress your friends at your next party with this neat trick.

Stay tuned for tomorrow’s post when I’ll share even more BlackBerry API gems with you!

About Denver C.

Denver Coneybeare has worked for RIM since graduating from University of Waterloo in Waterloo, Ontario, Canada in 2005 with an Honors Computer Science degree. His roles at RIM have included automated API test developer, API designer and developer, and currently, Team Lead - Java Device APIs. Denver was drawn to API development by the unique challenges that public API design present, that simply are not there when developing code for one's own consumption. With a natural eye for usability, compatibility, and quality, the APIs that Denver has been in charge of are (in his own humble opinion) the best in the world... well, maybe not, but he thinks they're pretty good :)

Join the conversation

Show comments Hide comments
+ -
blog comments powered by Disqus