How to avoid creating BlackBerry apps with memory leaks

by The PocketBerry Team

29 October 2009 No Comment

bbmemleak

Memory leaks are annoying for everyone. Continuous applications and themes release each and every day causing these tragic incidents. RIM has went ahead and posted how to get around having memory leaks when creating applications on the BlackBerry Developer Blog. Maybe this will be an end to battery pulls and we won’t have to rely on applications such as QuickPull so much. Continue reading to see the full post from the BlackBerry Developer Blog.

Let’s start by clarifying how developers can end up with a memory leak in a Java® development environment. The Java Virtual Machine performs garbage collection on demand which frees up memory allocated by objects not referenced by anything else in the system – this puts Java applications in a better position than applications in a development environment like C++, for example. However, when an object that’s not needed anymore is left referenced by another object in your application, the JVM system has no way to know that this object should be freed up. This is especially true if instances of such an object get accumulated over time.

Our experience with BlackBerry development shows that in practice one of the most common cases for the creation of a memory leak is when registering listeners for system-wide events – for example, when registering your own email folder using ApplicationMessageFolderListener. However, a memory leak can be created by just adding an object instance to the global runtime store and never removing it. Here is a very simple application that creates a new leak every time it is started:

import net.rim.device.api.system.Application;
import net.rim.device.api.system.RuntimeStore;
import java.util.Random;

class TestMemoryLeaks {
    public static void main(String[] args) {
        //create a memory leak by adding an item to the runtimestore and never removing it
        RuntimeStore store = RuntimeStore.getRuntimeStore();
        store.put((new Random()).nextLong(), new TestMemoryLeaks());
    }
}

Of course, memory leaks can also exist within the scope of an application, but their impact is limited since they will be eliminated when the application terminates (unless the application is designed to always run in the background). In this category also fall all implementations of listeners registered for application-wide scope – for example AccelerometerListener. For such listeners, the underlying system uses WeakReferences; when the application terminates and no other objects have “strong” references to the listener, the system will automatically remove such WeakReferences and free up the objects.

In part two and three of this series, we’ll discuss how to detect a leak and identifying the root cause, respectively. Stay tuned!!

-by Mac Jadalhack

Source: BlackBerry Developer Blog