android-non-ui-to-ui-thread-communications-part-4-of-5
In parts 1-3 of this series, I have explored three different means for an Android non-UI thread to communicate user interface updates to the UI thread. The links below are to the series posts.
In this fourth installment, I want to show you how to use a broadcasts and a broadcast receiver to provide non-UI to UI thread communications.
BACKGROUND NON-UI THREAD TO UI THREAD COMMS
As background for those jumping into the middle of this series, non user interface (UI) threads are not allowed to make updates to the UI. For example, using a non-UI thread to update a TextView’s displayed text results in a CalledFromWrongThreadException. However, 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 Android Not Responsive errors. So you need to have non-UI threads perform larger/bigger computing tasks, but need those threads to be able to communicate updates back to the UI thread to perform display updates.
In the first three posts, I showed how to use an activity’s runOnUiThread() method, a view component’s post() method, and the Android Handler Framework to have the non-UI thread send a user interface update request back to the UI thread for display. Each of these past three options take advantage of the underlying UI event message channel to message the UI thread to perform the user interface update. In this post, I show you a different means of providing the communications via broadcast intent that is acted on by a BroadcastReceiver on the UI thread.
SIMPLE APP
A simple application (called Simple App) will again be used to demonstrate the use of broadcast messages 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.
The application code for this simple example is provided here.
OPTION 4 – USING A BROADCAST
Broadcasts are Android Intents that indicate some action has occurred. Some broadcasts are system broadcasts. For example, one of the built in Android broadcast is that the battery is low. You can create your own custom broadcasts as well.
Broadcast receivers are components in the application that listen for broadcasts and take some action. You could, for example, build a broadcast receiver to listen for the battery getting low broadcast event in order to inform the user that unsaved data should be saved quickly. Of course, you can also build a broadcast receiver to listen for your own custom application broadcasts.
So, a broadcast and broadcast receiver can be used to accomplish the non-UI to UI thread communications. The non-UI thread can publish a broadcast intent that a broadcast receiver associated to the UI thread uses to perform the UI update.
Now, per the Android documentation on BroadcastReceivers, if your custom application broadcasts are not going to be used across applications, you should consider using a LocalBroadcastManager to send a local broadcast versus a system broadcast. A LocalBroadcastManager’s intent broadcasts are not broadcast to other applications. They are therefore a bit more efficient and secure than using a general broadcast message. You can read a prior blog post of mine to learn more about LocalBroadcastManager and local broadcasts.
Therefore, given the fact that the non-UI to UI thread communication is local to your application, I would recommend (and will show below) using the LocalBroadcastManager to perform the thread communications.
PUBLISHING THE BROADCAST
First, from the non-UI thread, create an Intent that provides the necessary information to the UI thread about the user interface updates that are required. In this example, the non-UI thread simply provides the new random number that was generated as extra data (under the key of “result”) in the Intent. Then use an instance of Android’s LocalBroadcastManager to send the local broadcast.
|
1
2
3
|
Intent intent = new Intent("com.intertech.random.generation");
intent.putExtra("result", text);
LocalBroadcastManager.getInstance(ShowSomethingActivity.this).sendBroadcast(intent);
|
SET A BROADCAST RECEIVER LISTENING
On the UI thread, you need to create an instance of BroadcastReceiver to listen for updates coming from the non-UI thread. In this simple application, I created an anonymous BroadcastReceiver instance from within the createBroadcastRecevier() method which is called from the onCreate( ) method of the application’s main activity.
|
1
2
3
4
5
6
7
8
|
private BroadcastReceiver createBroadcastReceiver() {
return new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
updateResults(intent.getStringExtra("result"));
}
};
}
|
The updateResults() method of the broadcast receiver gets the TextView and updates the string with what is in the broadcast’s extra data at “result”.
Once the broadcast receiver is created in onCreate(), use a LocalBroadcastManager to register the UI thread for the broadcasts sent by the non-UI thread, specifically those with the string action of “com.intertech.random.generation”);
|
1
2
3
4
5
6
7
8
9
|
@Override
protected void onCreate(Bundle savedInstanceState) {
...
resultReceiver = createBroadcastReceiver();
LocalBroadcastManager.getInstance(this).registerReceiver(resultReceiver, new IntentFilter("com.intertech.random.generation"));
...
}
|
Now, once the non-UI thread publishes its local broadcast, the broadcast receiver listening for the message gets the Intent and takes on the responsibility of updating the UI on the UI thread.
As a last bit of housekeeping, make sure to unregister the broadcast receiver when the communication between non-UI and UI threads is no longer needed. In this example, I unregister the BroadcastReceiver in the onDestroy() method of the main activity.
|
1
2
3
4
5
6
7
|
@Override
protected void onDestroy() {
if (resultReceiver != null) {
LocalBroadcastManager.getInstance(this).unregisterReceiver(resultReceiver);
}
super.onDestroy();
}
|
CONSIDERATIONS OF OPTION 4 – BROADCASTS
The broadcast option is not reliant on the message event queue. Instead it relies on a different Android set of components; namely the Intent and Intent listener called a broadcast receiver. This sub-framework has pluses and minuses. There are no convenience methods as provided through methods like post() and runOnUiThread() using the thread’s event queue. Some consider working with Intents, BroadcastReceivers (and LocalBroadcastManager) a bit more complex. However, the broadcast intent can conveniently carry quite a bit of data to the UI thread from the non-UI thread. Also importantly, the non-UI thread and UI thread do not have to share any component knowledge. So the non-UI thread is quite decoupled from the UI thread. The only information shared by the two threads is the name of the intent action.
WRAP UP
Just one more post in this series. In that post, I’ll show you how to use an AsyncTask’s for do long running work on a separate non-UI thread, while still being able to push changes to the UI via special UI thread methods.
Please connect with Intertech if you or your organization could use help on your Android/mobile project.
Read more: http://www.intertech.com/Blog/android-non-ui-to-ui-thread-communications-part-4-of-5/#ixzz3Myuoh9Jf
Follow us: @IntertechInc on Twitter | Intertech on Facebook