I have been working on a small Android app that, in a nutshell, goes out to the internet, grabs an XML file, parses it, and sticks it in the local database on the phone. Currently, I am writing ~937 records in to the database after reading this XML file. Needless to say, this takes some time. As a result, I throw the work in to a thread, and then put a dialog on the screen indicating that I am working on it.
The code I am using to spin up the thread is here (modified to make it short and sweet) :
Hopefully, this code is pretty straight forward. It spins up a new thread, initializes the XMLDataParser class, while passing in the URL that I am getting the data from. If you were to add this code to a project, you would find that a thread was spun off, and was doing its thing. (Though, you wouldn't really be able to tell that it was actually doing anything. We'll get to that in a second.)new Thread(new Runnable(){
public void run(){
try {
dp = new XMLDataParser(getURLPath());
dp.parse();
System.out.println("Update db.");
updateDatabase();
} catch (Exception e) {
System.out.println("Exception : " + e.getMessage());
// Display an error.
}
}
}).start();
You could just throw up a progress dialog with a spinner before you start the thread, and then attempt to close the dialog when the thread is done. In my adventures, I attempted this, and actually managed to make it work! There are even supported ways to make the dialog go away when the thread is done. However if you do this, you are going to end up in one of two "difficult" situations :
- When the screen orientation changes, the thread will finish running, but your progress dialog will go away.
- When the screen orientation changes, the thread will try to access something in the Activity that was destroyed by the OS, and you will crash.
So, how the heck do we make that happen?
Well, we know that when the screen orientation changes the current Views and Activities are destroyed, and new ones are created. A little bit of messing around will also show us that the thread we started continues to run even after the Views and Activities are destroyed. So, "all" we need to do is figure out how to make it so that the thread can communicate with the newly created Views and Activities.
So, lets break this down in to two parts.
- Making something survive the screen rotation.
- Having that something update our newly created Activity and Views.
How to survive a rotation
If you have done much development, you may think the magic way to deal with this is to stick something in your bundle that will be passed to the newly created Activity. While it is possible that you might be able to make that work, we want to have an entire object survive the restart. To do that, we need to add onRetainNonConfigurationInstance() to our activity class. When the screen is rotated, this method is called, and allows us to return a class (derived from Object) that can be retrieved from the new Activity. Generally, you want this method to do as little as possible, since it will be called during the screen rotation. Here is a bit of code from my application showing the call :
@Override
public Object onRetainNonConfigurationInstance() {
return myGUIUpdateHandler;
}
All we are doing is returning the object that we want to have access to when our current activity is destroyed, and the new one created. Once the new Activity is created, we can get the pointer to the object back by calling getLastNonConfigurationInstance(). Once we have done that, we will again have access to the object that we were attempting to save.
Which brings us to :
Having something update our newly created Activity and Views
Now, for the fun part. We can pass an object between the two Activities, so now we can just pass the ProgressDialog object we were using, call .show(), and everything just works, right?
No, not really. The ProgressDialog will be bound to our old View that was part of the Activity that was destroyed. So, attempting to work with it would end up crashing our application.
Instead, we want to create a handler that will allow us to pass messages between threads. In the Handler class, we want to override the handleMessage() method so that when a message comes in, we can do something with it. Here, again, is a sample from my code :
In this handler class, when the UPDATEDATA case is called, we want to update our UI thread. This could be something such as updating the status bar in our program.
public class ThreadEvents extends Handler {
// Set up a random unique ID for message handler
public static final int UPDATEDATA = 12346;
// @Override
public void handleMessage(Message msg) {
switch (msg.what) {
case UPDATEDATA:
System.out.println("Thread sent us an update data event.");
break;
default:
break;
}
super.handleMessage(msg);
}
}
The last piece of the puzzle is how to actually send events to this handle so that we can process them. The first thing that needs to be done before a thread can send a message through a handle is the handle class needs to be created prior to the thread being started. By doing that, the child thread will also have a pointer to the handler class. Then, any time the thread wants to send something to the parent thread, it only has to do something like this :
message = new Message();
message.what = ThreadEvents.UPDATEDATA;
myGUIUpdateHandler.sendMessage(message);
The final trick to making the ProgressDialog survive a screen rotation is to create a new instance of the dialog when an activity is started, and there is an object available from getLastNonConfigurationInstance(). Then, to update that new ProgressDialog instance as events come in from the child thread.
Final thoughts :
Obviously, I have not provided enough sample code here to do a full implementation. That never was the goal, so please don't post a follow-up asking for it. It is my experience that people that have to work a little to obtain knowledge keep it longer. My goal was to point you in the right direction so you can put the remaining pieces in place.
I also suspect that it might be "better" to use an AsyncTask to achieve the same ultimate result. However, this is the first method I discovered to achieve my goal. In the future, I intend to try doing the same thing with an AsyncTask, and will post another entry when I get around to that. In the mean time, this method seems to work well as I have been able to rotate the screen back and forth several times during a long operation without crashing my application.
