Timer(Task) = bad! Do it the Android way: Use a Handler :)

Well, after programming a while for Android I got in touch with some things that are different from usual Java. I already mentioned that before, when I decided to start writing about my experiences with Android: Android & Memory (Leaks) ;)

This time I’d like to write a bit about Timer and TimerTask and why you shouldn’t use them…

While coding for a project I noticed that updating the gui out of a TimerTask didn’t work everytime and specially didn’t work good. Actually it basically never worked and at first I just couldn’t figure what was going on. I put some debugging stuff in the timers and everything seemed to be fine, as the debug messages appeared in the Log. Still: the gui wasn’t affected at all :oogle:
So I started with some research and found a lot of people with same effects but just few answers (kind of get used to that ^^). So after some time I found an article on Android Developers: Updating the UI from a Timer. The author is describing a kind of similar problem to mine but still not the same. Anyway, he’s also talking about “The Android way” which basically says: Timer(Tasks) are bad! Do it the Android way: Use a Handler :) Interesting idea so I gave it a try and now it works perfectly :mrgreen:
I also found some more sources reporting about better performance using handlers and stuff like that (I might look that up again and post some links).

As you can see in the code snippet, it’s pretty easy to go that way too:

First we need a Handler that starts the Runnable after 100ms

private Handler handler = new Handler();
handler.postDelayed(runnable, 100);

And we also need the Runnable for the Handler

private Runnable runnable = new Runnable() {
   public void run() {
      /* do what you need to do */
      /* and here comes the "trick" */
      handler.postDelayed(this, 100);

So the “trick” is to tell the handler at the end to start the Runnable again. This way the runnable is started every 100ms, like a scheduleAtFixedRate() TimerTask! If you want it to stop, you can just call handler.removeCallback(runnable) and it won’t start again, until you tell it to :thumbup:
There’s also another advantage of this solution: You don’t have to create new Timer(Task)s all the time and can reuse the one Handler and Runnable.

By the way, to get notified about new posts, just enter your email address on the right :)


  • Thanks for this , it works great…

  • Helped a lot. Thanks.

  • *This way the runnable is started every 100ms*

    This is not entirely true. The runnable is started every 100ms + the time that is needed to execute the foobar() method :)

  • This post is from 2010. Does it remain valid? Are the Timer and TimerTask still with some sort of bugs?

  • Yes they are. TimerTask still, on some devices (I don’t know the real reason why), doesn’t update the UI.

  • As I said, that’s because you’re not calling runOnUiThread, TimerTask is creating a new thread and the code interacting with the UI must be run on main thread, so you need to invoke it with runOnUiThread, it’s exactly the same as on Windows, you can’t modify the interface unless you’re on the main thread, you need to call Control.Invoke to run the code on main thread.

  • thank you…

  • This will just run something every 100ms. But what if you need a timeout so it doesn’t keep going? One possible way it to run a second handler.postDelayed() that runs after the timeout duration and calls handler.removeCallbacks(this); I havent tried it so YMMV.

  • How to exit or close this handler and runnable

  • Thanks, This tutorial helped me a lot and I was searching for this topic since last three days…..

  • Must call the method removeCallbacks when you do not use the Runnable.

  • Nice alternative, but have the thread issue.
    A handler is not a thread. It is a handler for Android messages.
    In order to receive messages it need a looper, which sit on a thread.
    When you create a handler in this way it sit on the thread that you are currently using, which is probably the GUI thread (if you are called directly bu main activity class).
    A TimerTask is a creating a separate thread.
    That explain why the handler is synchronised with GUI, while TimerTask is not.
    However when you do need a separate thread you can create a HandlerThread and use its looper for your handler, you then can call postDelayed and use your newly created thread.

  • thanx dude, u r great.

  • This works very nice, cool!. I think there’s a typo though. For stopping it, it should be “handler.removeCallbacks(runnable)” (with an “s” there at “Callbacks”)

  • Pingback: How to update variable and show in UI on 1000 millie intervals [duplicate] - ExceptionsHub

  • I love you so much bro! You saved my life!

  • Pingback: [android] Rxjava ? ??????????????? | ???????

  • Hi, thanks for your code! have you figured out how to solve the issue you have when calling handler.removeCallbacks(runnable);
    to stop the runnable?

Leave a Reply