Archive for March, 2010

Android Threads

Wednesday, March 3rd, 2010


For the past few weeks, I have been looking into development for the Android mobile device operating system. Development for this operating system requires the use of the Java programming language with additional libraries provided by the publicly available Android SDK. As such, I’ve ventured back into the world of Java, as well.

Hopping into Android development is very easy by utilizing the provided Android Tutorials. However, there are a few tricks here & there that one does not easily find, which brings me to the current blog post.

Threading in Android one would believe would be identical to how one creates and handles threading in Java. However, there are a few intricacies that one must obey in Android whereas in Java they need not be required. For example, in the following Java class, it displays a simple text field that a thread updates with the current UNIX timestamp:

import javax.swing.JFrame;
import javax.swing.JTextField;

import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;

public class TestJava extends JFrame implements Runnable {
	
	private JTextField textField = null;
	private boolean runThread = true;
	
	public TestJava() {
		this.textField = new JTextField();
		this.add(this.textField);
		this.setTitle("Testing Java");
		this.addWindowListener(new WindowAdapter() {
			public void windowClosing(WindowEvent we) {
				runThread = false;
				System.exit(0);
				return;
			}
		});
		Thread counterThread = new Thread(this);
		counterThread.start();
		this.pack();
		this.setVisible(true);
		return;
	}
	
	public void run() {	
		while(runThread) {
			this.textField.setText("" + System.currentTimeMillis());
		}
		return;
	}
	
	public static void main(String[] args) {
		TestJava test = new TestJava();
		return;
	}
}

This is pretty straight-forward, modifying the JTextField from within the run function. However, in Android, only the thread that owns the UI interface can update said interface, which causes a few complications. The following class in Android will perform (roughly) the exact same as the prior class did within the standard Java libraries:

package com.andrewmkane.test;

import android.app.Activity;
import android.os.Bundle;
import android.os.Handler;
import android.os.Message;
import android.widget.TextView;

public class ThreadActivity extends Activity implements Runnable {
	
	private TextView textview = null;
	private boolean performThread = false;
	
	protected void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		textview = new TextView(this);
		this.setContentView(textview);
		return;
	}
	
	protected void onStart() {
		super.onStart();
		this.performThread = true;
		Thread counterThread = new Thread(this);
		counterThread.start();
		return;
	}
	
	protected void onStop() {
		this.performThread = false;
		super.onStop();
		return;
	}

	public void run() {
		while(performThread) {
			handler.sendEmptyMessage(0);
		}
		return;
	}
	
	private Handler handler = new Handler() {
		public void handleMessage(Message msg) {
			textview.setText("" + System.currentTimeMillis());
			return;
		}
	};
}

In the class above, you’ll notice that instead of setting the text of the TextView (akin to a JTextField), we set the value within the private Handler object. This is done because the run function is housed within a separate thread, while the Handler object is held within the primary UI thread.

This way, our secondary thread sends a message to the Handler located in the primary thread. The primary thread, which has access to the UI, then is able to modify the TextView without being denied access, whereas the secondary thread (within the run function) would have been. It’s a bit complicated, but makes sense – limiting the UI to a single thread allows developers to run processes in the background without accidentally mucking up the UI all the while making sure the UI has a dedicated thread to maintain decent performance.