Question

I have a simple Android app which uses AsyncTasks for I/O. A frequent pattern:

• User clicks a button
• In response, an onClick handler instantiates and .execute()s an AsyncTask
• Once the AsyncTask completes, the UI should be updated in some way

According to the documentation for AsyncTask, the correct way to accomplish the UI updates is to override onPostExecute in the AsyncTask class – this will be invoked back on the UI thread after execution and thus can touch the widgets, etc.

However, it seems wrong to me that onPostExecute should have any sort of hard reference to a UI element. I would prefer to keep my I/O tasks and UI code separate. Instead, this seems the obvious situation where I should pass an opaque callback to the AsyncTask – the callback retains a reference to the UI elements and thus we maintain isolation and reusability in the code. A classic delegate pattern (or perhaps listener, event, etc, many options here).

As an example, the code below seems wrong to me:

    class QueryJobsDBTask extends AsyncTask<Void, Void, ArrayList<ContentValues>> {

    @Override
    protected void onPostExecute(ArrayList<ContentValues> freshJobsData) {
        someList.clear();
        someList.addAll(freshJobsData);

        // BUG why does my DB query class hold UI references?
        someAdapter.notifyDataSetChanged();
    }

After some research, it looks like the Handler class is the most straightforward and lightweight way to accomplish a delegate pattern here. I can write reusable AsyncTasks for I/O and specify contextual UI update callbacks on a per-instance basis via Handler instances. So I have implemented this new Handler-enabled base class

   public abstract class HandlerAsyncTask<Params, Progress, Result> extends AsyncTask<Params, Progress, Result> {
    private Handler preExecuteHandler, postExecuteHandler;

    public void setPreExecuteHandler(Handler preExecuteHandler) {
        this.preExecuteHandler = preExecuteHandler;
    }

    public void setPostExecuteHandler(Handler postExecuteHandler) {
        this.postExecuteHandler = postExecuteHandler;
    }

    @Override
    protected void onPreExecute() {
        if (preExecuteHandler != null) {
            preExecuteHandler.sendMessage(Message.obtain());
        }
    }

    @Override
    protected void onPostExecute(Result result) {
        if (postExecuteHandler != null) {
            Message msg = Message.obtain();
            msg.obj = result;
            postExecuteHandler.sendMessage(msg);
        }
    }
}

And voila, all of my I/O tasks are now properly partitioned from the UI – and I can still specify simple UI update callbacks when needed via Handler instances. This seems straightforward, flexible, and superior to me … so of course I wonder what I’m missing.

How is the current framework solution superior? Is there some major pitfall to this approach? To my knowledge the topology of code execution and threads is the exact same at runtime, just code coupling is looser (and a few extra frames on the stack).

Answer 1

This is an elegant solution for segregating UI/Background tasks in small projects, although passing Runnables is even more elegant. Keep in mind that the AsyncTask is a wrapper around Thread/Handler, so you’re doubling up on the thread-messaging that’s already going on behind the scenes. The flaw here is that if you design the AsyncTasks to be reusable, you’ll need to make sure that the IO you’re running are all thread-safe, as there’s no communication between the various AsyncTasks as to who is active or accessing which resources. An IntentService might be more appropriate if you need to queue background tasks rather than just fire them.