Android Non-UI to UI Thread Communications(Part 3 of 5)

Original:http://www.intertech.com/Blog/android-non-ui-to-ui-thread-communications-part-3-of-5/

Continuing my series on Android non-UI thread-to-UI thread communications, this post covers use of the Handler Framework to facilitate the communications.  See here for Part 1 and Part 2 of the series.

Non-UI threads are not allowed to make updates to the UI.  Trying to do too much work (as defined as not allowing the user to interact with the UI for more than 5 seconds) on the UI thread leads to ANR errors.  In the first two posts, I showed how to use an activity’s runOnUiThread() method and a view component’s post() method to have the non-UI thread send a request through the underlying UI event message channel to the UI thread to execute a UI update.

ANDROID’S HANDLER FRAMEWORK

Android threads, in particular the UI thread, have a message queue.  Messages in the queue are processed by the thread in order of arrival.  In the case of the UI thread, user events (like a button push) cause event messages to be placed in the queue.  As explained in the previous posts, the runOnUiThread() and post() methods use this queue under the covers.  However, you can use the message queue more directly.

Using the Handler Framework, you can create a message directly and put the message on the UI thread’s queue from the non-UI thread.  The framework also lets you build a message handler to listen for the message on the UI thread.  Thus, the Handler Framework can provide another means for the non-UI thread to communicate with the UI via the framework pieces.

THE SIMPLEAPP REVIEW

As with the last post, I provide the simple application (called Simple App) to demonstrate the use of the Handler Framework for thread communications.  The app has two buttons to start/stop a non-UI thread.  The non-UI thread’s job is to simulate long running work by generating a random number, call the UI to have a TextView widget update the display of the random number, and then sleep for a number of seconds.

Now let’s see how the Handler Framework can be used in this app to update the UI (the TextView) from the non-UI thread.

OPTION 3 – USING THE HANDLER FRAMEWORK

First, create a Handler in the UI thread to receive and react to new messages sent by the non-UI thread.  Here are the steps to create the Handler:

1. Create class that extends android.os.Handler. For simplicity, I created the Handler subclass (called HandlerExtension here) as an inner class to the application’s activity.

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

private static class HandlerExtension extends Handler {        private final WeakReference<ShowSomethingActivity> currentActivity;      public HandlerExtension(ShowSomethingActivity activity){     currentActivity = new WeakReference<ShowSomethingActivity>(activity);   }      @Override   public void handleMessage(Message message){     ShowSomethingActivity activity = currentActivity.get();     if (activity!= null){        activity.updateResults(message.getData().getString("result"));     }   } }

The code here may look a little complex due to the static nature and WeakReference in the subclass.  If you try to create a simple class that extends Handler, you will find Eclipse and the SDK issues a compiler warning that the Handler class should be static or leaks might occur.

The issue is well explained in a * post.  While the code may be a little more complex, the post provides a great template example for creating the Handler subclass without memory leaks.

2. Next, add a property to hold the Handler subclass instance in the Activity.

 

1	Handler resultHandler;

3. Then, from the activity’s onCreate() method, create an instance of the Handler so that it can start processing any incoming messages from the non-UI thread.

 

1	resultHandler = new HandlerExtension(this);

Second, with the Handler subclass code in place, you can create a message from the non-UI thread and publish it into the UI thread’s message queue using the Handler subclass. Simply create an instance of Messageand add data to the message to indicate to the Handler what UI changes should occur (in this case, providing the random number that needs to be displayed in the TextView widget).

 

1 2 3 4 5 6 7 8 9

private void publishProgress(int randNum) {     Log.v(TAG, "reporting back from the Random Number Thread");     String text = String.format(getString(R.string.service_msg),randNum);     Bundle msgBundle = new Bundle();     msgBundle.putString("result", text);     Message msg = new Message();     msg.setData(msgBundle);     resultHandler.sendMessage(msg);   }

The SimpleApp example code for demonstrating option #3 can be found here(in an Eclipse project ZIP file).

CONSIDERATIONS OF OPTION 3 – HANDLER FRAMEWORK

The runOnUiThread() and post() methods examined in previous posts are really special Hander Framework conveniences.  They use the event queue on the UI thread to perform their task.  So why use the Handler Framework directly as shown here?  Using the Handler Framework directly is a bit more complex, but it allows you more control.  This is a generic framework for thread communication – any thread.  It also allows the non-UI thread to communicate without direct knowledge/ties to the activity or UI side components.  The non-UI merely has to post a message to a handler.

WRAP UP

In the final two upcoming posts of this series you will see different Android infrastructure to perform the non-UI to UI thread communications – namely the use of Broadcast Receivers and AsyncTask.  Stay tune for those posts.  If you are looking for some Android training or consulting help, look no further than the sponsor of this blog site:  Intertech.

 

Read more: http://www.intertech.com/Blog/android-non-ui-to-ui-thread-communications-part-3-of-5/#ixzz3MyuAnUgJ 
Follow us: @IntertechInc on Twitter | Intertech on Facebook