Archive for the ‘Google’ Category

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.

Google Maps hits a baby deer

Thursday, January 29th, 2009

It seems that images have been removed from Google Maps, but were luckily cached by the public when they were available detailing a Google Maps vehicle accidentally hitting a deer.

It seems the van pulled off to the side of the road, due to the mismatch of the markings on the road. Horrible, but also a bit comical.

I’ve always been very humored about the various things you could find on Google Maps, such as the large KFC ad:
httpv://www.youtube.com/watch?v=fsH4gws35ro

There are also a few car accidents, as well as breaks at the gas station, and my friend Zack.