1

What is the difference between Android timer class and creating one with a Handler?

i tried both ways and i understand they can do different things but i dont know why,for example with android timer class i cant update views and i think that is a huge limitation,but with a handler the code feels messy.

   Handler handler = new Handler();
   handler.postDelayed(new Runnable() {
       public void run() {
           //actions
       }
   }, 2000);   

}

So,what is the best to do a action every tot seconds?

Edit:this isnt a duplicate because im asking about updating views with timers.

3 Answers3

3

android.os.Handler is part of Android framework, the job will execute on the UI or main thread if you have created the Handler in the UI or main thread. Note that in Android you can only update views from the UI thread.

java.util.Timer on the other hand will execute on another thread so it cannot update the views.

So Handler is the recommended here. If you really want to use Timer you have to use runOnUiThread like:

new Timer().schedule(new TimerTask() {
    @Override
    public void run() {
        runOnUiThread(new Runnable() {
            @Override
            public void run() {
                //this will run on UI thread so you can update views here
            }
        });
    }
}, 2000, 2000);
Nongthonbam Tonthoi
  • 12,667
  • 7
  • 37
  • 64
  • 1
    In my personal opinion, this is even messier than using Handlers. What you are doing here, is creating a background thread that wakes up every 2000 ms just to tell the UI-Thread to do something. Additionally, you are limited by `runOnUiThread()` because you can only call it inside of an Activity. – Thomas Leyk Feb 16 '19 at 11:03
1

According to this answer : Android - Timertask or Handler , you're right about TimerTask class not being able to update views (cannot update the UI Thread). Definitely opt for Handler. The syntax looks clean to be honest.

R. Théo
  • 74
  • 1
  • 7
1

In my experience, Handler and the corresponding Android helper class HandlerThread are very flexible and allow you to do just about anything you need with regard to multithreading.

For example, running code on the UI-Thread:

Handler mUIHandler = new Handler(Looper.getMainLooper());
mUIHandler.post(new Runnable() {
    /* Do something on UI-Thread */
});

Doing work on a background thread:

// This thread still needs to be explicitly started somewhere
HandlerThread mBackgroundThread = new HandlerThread("ThreadName");
// Sometimes you still need to think about some synchronization before calling getLooper()
Handler mBackgroundHandler = new Handler(mBackgroundThread.getLooper());
// Execute code on the background thread the same way you would on the UI-Thread

Repeating a specific task after a given interval:

Runnable mTask = new Runnable() {
    // Run this task (every 1000 ms) on the thread associated with mHandler
    mHandler.postDelayed(this, 1000);

    /* Perform the Task */

    // You can also do this at the end if you wanted it to repeat 1000 ms AFTER
    // this task finishes.
}
Thomas Leyk
  • 186
  • 2
  • 8
  • Why would you use "Looper.getMainLooper()" isn't the default constructor enough? – David Oct 16 '19 at 09:59
  • @David According to the official documentation (https://developer.android.com/reference/android/os/Handler.html#Handler()), the default constructor binds the Handler to the Looper of the current thread, which may or may not be the UI-Thread. Also, specifying which Looper you want to associate with is more flexible and clearer. – Thomas Leyk Oct 16 '19 at 11:06
  • Goog point! Thanks. – David Oct 16 '19 at 12:48