Showing posts with label data. Show all posts
Showing posts with label data. Show all posts

Thursday, November 10, 2016

Android - Handlers and Data Leaks

This post is mostly for my reference as I use Handlers a lot, but I'm still trying to get use to the idea of a WeakReference. Obviously this isn't rocket science, but up until about 9 months ago I used Handlers in a very improper way (my first example) and undoubtedly ended up with a lot of data leaks in any multi-threaded application I developed.

I am writing this because I recently I was being tested on my Android knowledge, and although I knew about data leaks and how to solve the data leaks, courtesy of Android Studio, I didn't know what was actually causing the data leaks.

If not properly used a Handler will hold a reference to the context of the activity from which it was created which therefore prevents the garbage collector from performing garbage collection on the Activity from which you instantiated the handler. Here's a good example of what NOT to do.
class FooActivity extends Activity {
    private Handler mHandler;
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_foo);
        mHandler = createMyHandler();
        createBackgroundThreadWithHandler(mHandler);
    }
    private Handler createMyHandler() {
        return new Handler() {
            @Override handleMessage(Message msg) {
               super.handleMessage(msg);
               Toast.makeText(FooActivity.this, "Hi", Toast.LENGTH_SHORT).show();
            }
        };
    }
}

The above code is not good because we have no idea how long the BackgroundThreadWithHandler will be alive, however as long as it is, it will have a reference to the handler which will have a reference to the context of FooActivity.

So now lets look at the proper way to handle dealing with Handlers. We need to be able to create the handler, however we can't let the handler hold a strong reference to the Context/Activity.

class FooActivity extends Activity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_foo);
        createBackgroundThreadWithHandler(new MyHandler(FooActivity.this));
    }    

    void sayHi() {
        Toast.makeText(FooActivity.this, "Hi", Toast.LENGTH_SHORT).show();
    }

    static class MyHandler extends Handler {
        MyHandler(FooActivity fooActivity) {
            weakFooActivity = new WeakReference(fooActivity);
        }   
        @Override handleMessage(Message msg) {
            super.handleMessage(msg);
            FooActivity fooActivity = weakFooActivity.get();
            if (fooActivity != null) {
                fooActivity.sayHi();
            }
        }
    }
}

This example keeps a weak reference to FooActivity which allows the garbage collector to still perform garbage collection on FooActivity.

Friday, July 18, 2014

Passing Data Between Threads (Java)

Currently I'm working on a new desktop app for a family reunion. I started out hoping this would be a two day and done, but when I actually started coding I realized I was in a bit deeper than I had previously thought. So here's to explaining my app.

This app requires 2 windows to be constantly open and running, however both of these windows need constant communication.

The audience cannot see the control window, but rather only the pretty display, this allows for the audience to never see an annoying mouse moving around. I couldn't figure out any other way to do this the way I want with libgdx without multi threading.

I started this project by trying to create two windows using libgdx (however I didn't actually want libgdx for control) but I wanted to see if it was possible. I quickly learned that openAL does not allow libgdx to do that, so I quickly switched over to Swing to make sure that I could in fact actually still accomplish 2 windows (and not "pop ups").

So I started working at this app got a bit of the GUI out of the way then went on to the next challenge of communicating between these threads. Now the way that libgdx works you can't manage the threads a whole lot from the original class to start the threads, or at least in terms of passing around data.

The solution? A class I call DataPassage, with all variables being static. The static variables allow me to access the data from anywhere without having to directly pass it to each class. DataPassage nicely handles all variables inside. This helps in two ways.

#1) Cuts down in data on the heap.

#2) Organizes all variables and keeps it all in sync.

Now would I recommend this for all variables in every situation? No, but definitely useful in a lot of situations. Would I recommend this if you are struggling in a situation like mine? Yes. Just be sure to not be storing the variables in all 3 classes, and rather only in the DataPassage class.