Actually, having thought about this more, I recall my original intent
was to only spawn the thread for the time needed to do the task. That
means I don't have to worry about shutting down or closing the thread
when the application closes. (The task responds to the application
through one or more listeners that are Runnables, but it checks if
they are null before calling them.)
This approach assumes that the gc in Dalvik won't mind spinning up
objects and threads and destroying them regularly. I don't know if
that's better practice for the jvm, but this seems less likely to
produce leaks, right?
I changed the code to use a handler on the main thread. The handler,
when it receives a message, starts a new thread with the long-running
task. Unfortunately the handleMessage method is never called when the
object is built from my test code.
So let's take the threading out of it for a moment. Why does this
basic test case fail?
import android.os.Handler;
import android.os.Message;
public class TaskManagerExample {
// Test field for inspection
public boolean messageHandled = false;
private Handler handler = new Handler() {
@Override
public void handleMessage(Message msg) {
messageHandled = true;
}
};
public void start() {
handler.sendEmptyMessage(0);
}
}
import android.app.Application;
import android.test.ApplicationTestCase;
public class TaskManagerExampleTest extends
ApplicationTestCase<Application> {
public TaskManagerExampleTest() {
super(Application.class);
}
public void testHandlerShouldReceiveMessagesPostedToIt() {
TaskManagerExample example = new TaskManagerExample();
example.start();
try {
Thread.sleep(500);
} catch (InterruptedException e) {
}
assertTrue(example.messageHandled);
}
}
I put the sleep in there, just in case messages sent to the queue take
some time to get processed. Seems half a second should be plenty of
time (and keeps the test responsive). I tried it with five seconds and
it still fails.
What base *TestCase class should I be using the get Handlers, Loopers
and the MessageQueue to run under test?
--
Jeremy Wadsack
On Oct 8, 8:41 am, Lance Nanek <lna...@gmail.com> wrote:
> Handler has multiple constructors. The ones that take a Looper
> argument can take the Looper for a Thread other than the current one.
> That way you don't need to create the Handler on that Thread and it is
> easier to ensure it is not null on the Thread using it. There's also
> an android.os.HandlerThread utility class that is pretty much just a
> Thread with a Looper. It has a getLooper method that's easy to feed
> into the Handler constructor and that avoids the issue with prepare()
> taking a while sometimes and leaving you with a null longer than you'd
> expect.
>
> On Oct 7, 8:04 pm, DanH <danhi...@ieee.org> wrote:
>
>
>
> > Come to think of it, how would one create a Handler for another
> > thread? You'd have to dispatch the thread and have it create the
> > Handler and pass the pointer back to you (we won't worry about how),
> > but then that thread needs to go into a message receive loop.
>
> > Apparently this is done via Looper. I'm guessing the code would be
> > like this:
>
> > class LooperThread extends Thread {
> > public Handler mHandler;
>
> > public void run() {
> > Looper.prepare();
>
> > mHandler = new Handler();
>
> > Looper.loop();
> > }
> > }
>
> > You'd start this thread and then use your pointer to it to access
> > mHandler (though you'd have to guard somehow against getting a null
> > before the reference was set). Then dispatch Runnables or Messages
> > via that handler.
>
> > (Gotta wonder where Looper stashes the instance it creates of itself
> > to attach to the Thread. I suppose it uses ThreadLocal.)
>
> > On Oct 7, 4:38 pm, DanH <danhi...@ieee.org> wrote:
>
> > > But I don't see anywhere in the Handler spec where it says the thread
> > > will be dispatched. It appears to me that when the thread is posted,
> > > Handler will just run its "run" method, without starting the thread.
> > > If you wanted to run on a separate thread it appears to me that you'd
> > > have to start the thread, have that thread create a Handler and pass
> > > it back to you somehow, and then post via THAT Handler.
>
> > > At least that's how I'd interpret this: "Each Handler instance is
> > > associated with a single thread and that thread's message queue. When
> > > you create a new Handler, it is bound to the thread / message queue of
> > > the thread that is creating it -- from that point on, it will deliver
> > > messages and runnables to that message queue and execute them as they
> > > come out of the message queue."
>
> > > On Oct 7, 4:25 pm, Jeremy Wadsack <jeremy.wads...@gmail.com> wrote:
>
> > > > Fair point. The "// Do some tasks" is doing long-running (Internet-
> > > > connected) stuff, so I want it to run in a separate thread. As I
> > > > understand, posting the Runnable without a thread would run it on the
> > > > main thread.
>
> > > > I assume the gc will clean up the Threads as they expire, but I could
> > > > also redesign this to have a single active thread that posts Runnables
> > > > (or even just messages) to it's own MessageQueue at specified
> > > > intervals. Then I'd be managing the looper myself (that is, calling
> > > > Looper.loop), which would probably resolve this issue.
>
> > > > That doesn't answer the original question but it may be the right
> > > > approach if it's more "android-y".
>
> > > > --
> > > > Jeremy Wadsack
>
> > > > On Oct 7, 1:20 pm, DanH <danhi...@ieee.org> wrote:
>
> > > > > Kind of off-topic, but why are you creating a new Thread with each
> > > > > post, vs simply posting the Runnable?
>
> > > > > On Oct 5, 5:47 pm, Jeremy Wadsack <jeremy.wads...@gmail.com> wrote:
>
> > > > > > I have a class that uses a Handler for a timed, asynchronous
> > > > > > activity.
> > > > > > Something like this:
>
> > > > > > public class SampleClass {
> > > > > > private static final long DELAY = 30000;
> > > > > > private boolean isRunning = false;
> > > > > > private Handler handler = new Handler();
>
> > > > > > public start() {
> > > > > > if (!isRunning) {
> > > > > > isRunning = true;
> > > > > > handler.post(new Thread(task));
> > > > > > }
> > > > > > }
>
> > > > > > public stop() {
> > > > > > isRunning = false;
> > > > > > }
>
> > > > > > private Runnable task = new Runnable() {
> > > > > > public void run() {
> > > > > > if (!isRunning) {
> > > > > > return;
> > > > > > }
>
> > > > > > // Do some tasks
> > > > > > handler.postDelayed(new Thread(this), DELAY);
> > > > > > }
> > > > > > }
>
> > > > > > }
>
> > > > > > I am trying to write a unit test (without having to implement an
> > > > > > activity that instantiates the class) but I can't seem to get the
> > > > > > items that are posted to the MessageQueue to ever be fired.
> > > > > > Inheriting
> > > > > > from junit.framework.TestCase doesn't work, but then there wouldn't
> > > > > > be
> > > > > > a MessageQueue for the handler, I'd expect (although, there's no
> > > > > > error, but the Runnable never gets called). I tried inheriting the
> > > > > > test class from AndroidTestCase and ApplicationTestCase<Application>
> > > > > > but neither of those works, even though the former is supposed to
> > > > > > provide a Context and the latter "all the life cycle of an
> > > > > > application."
>
> > > > > > Anyone have any pointers?
>
> > > > > > --
> > > > > > Jeremy Wadsack
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
