BlackBerry Developer's Blog

[#1]

 

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 partywith this neat trick. 

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

Message Edited by dconeybeare on 08-17-2009 10:33 AM

[#2]

Can the code samples be text? Having them as images seems a little silly.

[#3]

Yeah, you're right.  In today's post I put the source code in as text.  Thanks!

[#4]

Thanks, I could never figure out what is/how-to use the WeakReference.

[#5]

Thank you, i could not figure out weakreferences either! haha

[#6]

Re. using WeakReferences to determine if your application is running.  Where would this be useful?  If the application is no longer running then wouldn't the code that calls isAlive also stop running?

[#7]

Maybe using a WeakReference would be useful when one launches a new screen from another screen and then closes the former. That way the closed screen and all it's objects would be garbage collected. Am I right?

[#8]

In response to rumplestiltskin...

You are right that in general invoking Application.isAlive() to determine whether or not an application is running is a good way to do it.  When an application exits then all threads of that application are destroyed and most of the application is garbaged collected.  The example that I gave above was somewhat contrived, but would be useful if one application wanted to determine if another application was alive without preventing its Application object from being garbage collected.

As a more realistic example, suppose you register a PhoneListener with the net.rim.blackberry.api.phone.Phone class.  Even after your application exits the listener will be referenced and will be notified of phone events.  So if the implementation of PhoneListener holds a strong reference to the Application object then it will not be able to be garbage collected.  In this case, holding a weak reference to the Application object in the PhoneListener prevents this problem, especially since an Application object is more-or-less useless after the application it represents has exited.

Hope this makes sense.  Feel free to continue the discussion!

--Denver

[#9]

In response to Cristian J, "Maybe using a WeakReference would be useful when one launches a new screen from another screen and then closes the former. That way the closed screen and all it's objects would be garbage collected. Am I right?"

I'm not sure I fully understand what you mean.  When you say that a screen "launches" another screen do you mean that it pushes another screen onto the display stack using UiApplication.pushScreen()?  If so, I don't think that a weak reference would be of benefit in this case because screens do not have any implicit references to other screens on the display stack.  Once a screen is closed (a.k.a. removed from the display stack) then it and all of the objects it recursively references are available for garbage collection, assuming that no other references to those objects exist.

Let me know if I misunderstood your question and I'll attempt to clarify.

[#10]

If your listener implementation held a WeakReference to the app then yes your app would be able to be GCed but you still have the listener hanging around after the app terminates which is not good.  I think it would be best practice to tear down your listener when the app exits.  In conjunction with this I think it would make sense for the implementation of Phone's listener dispatcher to hold weak references to the listeners themselves.  That way the system ensures that misbehaved apps that do not deregister themselves don't stick around forever as zombie processes.  Phone is one example but there are other global listener registries in the system that I think would benefit from holding Weak references to their listeners ( LowMemoryManager for example).

Another prime use of weak references would be implementing a cache.