Be Careful With Static Stuff on AsyncTask
Run an activity, which detected that we had no data, raised a dialog, and finished once the dialog closed.
Along the way, the activity sent a command to an
IntentServiceto go get the data.
The next time you would launch the activity, you would get a warning about “sending message to a Handler on a dead thread”, and the activity would not fully start.
I, being a bit cocky, assumed that the problem was something with the WIMM environment.
Ummmm… not so much. I screwed up. In fact, I had seen reference to this problem before, but never fully appreciated what it meant until I ran into it myself.
The problem was that the load-the-data logic for the activity was using
AsyncTask. That, on its own, is not a problem — in fact, it’s
desirable (particularly on environments where you can’t use loaders).
AsyncTask has static data members. And one of the limitations
of those static data members is that they need to be initialized on the
main application thread.
Normally, this is not a problem, as you usually only reference the
AsyncTask class on the main application thread, when you go to create
your first instance of the task to execute.
In my case, though, I had moved some common logic into a static method
AsyncTask subclass… and I was calling that static method from
onHandleIntent(). That was the first time I
AsyncTask subclass, and it was on a background thread.
That initialized a static
Handler used by
AsyncTask on the background
thread, not the main application thread.
The error message was pointing out that the
was associated with a thread (the one from
was now dead.
The solution: simply move the static method elsewhere.
The moral of this story is to be very careful about when you first use
AsyncTask. Some people have resorted to using a custom
object and touching an
AsyncTask subclass in
onCreate(), just to make
sure that it is properly initialized. While IMHO that is not necessary,
you do have to pay attention.