Handler and Looper: Android's Threading Backbone
A Looper is a worker that endlessly processes a queue of tasks for a thread. A Handler is how you give that worker a new task from another thread, like updating the UI. The footgun is blocking the main thread's Looper, which freezes your app.
Why it exists
Android's UI toolkit is not thread-safe, meaning only the main thread can safely modify UI components. This creates a problem: how do you perform long-running operations like network requests without freezing the UI, and then communicate the result back to update the screen? Handler and Looper provide the fundamental messaging system to solve this.
The mental model
Think of a Looper as a dedicated assembly line worker for a single thread, endlessly processing items from a conveyor belt (the MessageQueue). Other threads can't place items on the belt directly. Instead, they give their tasks to a Handler, which acts as a dispatcher, placing the task onto the correct conveyor belt to be processed in order by the Looper.
How it works
A thread gets a Looper by calling Looper.prepare(), which creates a MessageQueue for it. Calling Looper.loop() starts an infinite loop, pulling Messages or Runnables from the queue and executing them. A Handler is always tied to a specific Looper and its thread. When you call handler.post(runnable), the Handler enqueues that work into the Looper's MessageQueue. The Looper eventually dequeues and executes it on its own thread. The main UI thread has a Looper created by the system at startup, so you can always post to it.
When to use it
The primary use is to communicate from a background thread to the main UI thread. After a background task completes, you use a Handler associated with the main Looper to post a UI update. You can also use this pattern to create your own dedicated background threads that process tasks sequentially, one after another, which is useful for stateful operations that shouldn't run in parallel.
When not to use it
For most modern application development, higher-level abstractions like Kotlin Coroutines are preferred for managing background work and concurrency. Coroutines provide structured concurrency, better cancellation, and cleaner error handling, abstracting away the manual Handler/Looper mechanism. Use Handlers directly when you need a simple sequential task queue or for low-level framework interaction.
One canonical example
To update a TextView from a background thread, you first get a Handler for the main thread's Looper: val mainHandler = Handler(Looper.getMainLooper()). From your background thread, you then post your UI update work: mainHandler.post { myTextView.text = "Updated from background!" }. This lambda will be executed safely on the main thread.
Interview question
How does Android's Handler/Looper mechanism enable safe UI updates from background threads?
- a.A new Looper is created on the background thread, which then processes UI update requests.
- b.Background threads directly access and modify UI components once their work is done.
- c.A Handler tied to the main thread's Looper enqueues UI update tasks for execution on the main thread.Correct
- d.The background thread temporarily takes control of the main thread's execution to perform UI modifications.
Why? this is the answer
The correct answer is C because a Handler associated with the main thread's Looper is used to post UI update tasks, ensuring they are executed safely on the main UI thread. Option B is incorrect as Android's UI toolkit is not thread-safe, prohibiting direct UI modification from background threads.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #concurrency
- #threading
- #kotlin
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles