A Deep understanding of Android Handler

The main thread of our Android application is very complex as it has to handle lots of different work including user interactions as well as the various system events that our app listening to.

The main thread is also called a Looper thread because it has a Looper. A looper has a message queue to which all work such as user interactions and system events are fed and then the main thread receives the work it has to do from this queue.

The Looper reads that work off the message queue, dispatches it out to something called a Handler, and it's the Handler that performs the work.

The main thread has a default Handler that does most of the system work. 

We can also create our Handlers using Handler class and associate it with a looper which means that we can write our code that takes advantage of this capability of placing work into a queue, then having that work dispatched out to a Handler.

The Looper thread is a very powerful concept. as we have mentioned, it contains a Looper and a MessageQueue, and it can dispatch work out to instances of the Handler class. Our main thread is the most common instance of the LooperThread we interact with, but our application can create additional Looper threads if we need them. But our main point of interaction are the Handlers because the Handler allows us to do the work we need to do on our Looper thread.

So we can use an instance of a Handler to enqueue work into thee message queue of a Looper thread and then the Looper encounters that work, it will then dispatch the work back out to that Handler instance.

So by using a Handler, we're doing our work in two stages. We're queuing up the work in the message queue, and then we're later performing that work within the Handler.

When we construct an instance of the Handler, it has to be associated with a Looper. We can do that by using the Looper class static method, getMainLooper(), that will allow us to get a Looper associate with the main application thread/

Code: Create an Handler object:

var myHandler = Handler(Looper.getMainLooper())

And the important reason is that once you construct a Handler, that Handler is bound to that Looper. Now what that means is if you use a Handler instance to enqueue work, you can enqueue the work form any thread in your application you want to, but the work itself will always be performed on the thread of the associated Looper. So now this idea of a Handler being bound to a Looper on a particular thread opens us up to some powerful solutions. One of the things we can use our Handler for is sending work to one thread from another.

Code: Posting Job from any thread to Main thread using handler


 //The code that you want to run on Main Thread.


This is how the AsyncTask class works. The AsyncTask class uses a handler to switch between the work done on the background thread and the work done on our main application thread.

Handlers also allow us to schedule work to be performed in the future.  When we use a Handler to place work into the message queue, we can indicate that we don't want that work peWprkrformed until sometime in the future, and then the Looper will take care of the details of dispatching that work to our Handler at the right time.

Code : To run a job in future (After some time):


 //The code that you want to run on Main Thread.


 1000 // Time in milisecond


Post a Comment

Post a Comment (0)

Previous Post Next Post