Why should there be a handler mechanism

In the development of Android UI, we often use handler to control the interface changes of the main UI program. With regard to the role of handler, we conclude that working with other threads, receiving messages from other threads and updating the contents of the main UI thread through the received messages.

We assume that in a UI interface, there is a button, when clicked on this button, the network connection, and a string on the network down to show a textview on the interface above, there is a problem, if the delay of the network connection is too large, may be 10 seconds or longer, Then our interface will be in a state of suspended animation, and if this time is longer than 5 seconds, the program will appear abnormally.

At this point, we would like to use the thread to do the above work, that is, when the button is pressed to open a new thread to complete the network connection work, and to update the resulting results to the UI. However, this time another problem arises, in Android, the main thread is non-thread-safe, that is, UI updates can only be done in this thread, other threads cannot directly manipulate the main thread.

In order to solve these problems, Android designed the handler mechanism, which is responsible for communicating with the sub-thread by handler, so as to establish a collaborative bridge between the child thread and the main thread, so that the problem of Android UI update can be solved perfectly. The following example illustrates the basic use of handler.

Baidu Experience: jingyan.baidu.com

Tools/Materials

• Eclipse ADT

Baidu Experience: jingyan.baidu.com

Method/Step

2. 1

   How the handler works

   In general, we bind the handler in the main thread and create a new thread on the event trigger to complete some time-consuming operations, and when the work in the sub-thread completes, a complete signal is sent to handler, and handler receives the signal, the main UI interface is updated.

3. 2

   Handler and child thread collaboration instances

   1, create the handler implementation class, in the main UI in the same class as the inner class

   Class MyHandler extends Handler {

   Public MyHandler () {}

   Public MyHandler (Looper L) {

   Super (L);

   }

   Overriding the Handlemessage method, accepting data and updating the UI

   @Override

   public void Handlemessage (Message msg) {

   Super.handlemessage (msg);

   The UI action is based on the MSG content here

   }

   }

   2, sub-threading implementation

   Class MyThread implements Runnable {

   public void Run () {

   Message msg = new Message ();

   Bundle B = new bundle ();

   B.putstring ("cmd", "Update");

   Msg.setdata (b);

   MainActivity.this.myHandler.sendMessage (msg);

   Notification handler Update UI

   }

   }

   With the above two implementations, we only need to declare the MyHandler instance object in Mainactivity to complete the communication between the threads and the interface update operation.

   MyHandler MyHandler = Newmyhandler ();

Why should there be a handler mechanism