Android in App Show dialog is a very easy thing to do, but I never tried to show dialog inside the service.
Experience UI operation to be in the main thread, the local service is the main thread of the correct, but the remote service inside the display dialog, sound should not be in the main thread inside it?
Try to know, wrote a aidl call, the client side to call Aidl. On the service side is to show a dialog.
The aidl part is ignored. The code on this side of the service is the same as the activity shows dialog.
Alertdialog.builder Builder = new Alertdialog.builder (mcontext); Builder.settitle ("TEST"); Builder.setmessage ("test"); Builder.show ();
Of course dialog to Settype (WindowManager.LayoutParams.TYPE_SYSTEM_ALERT);
As a result, it's tragic.
Can ' t create handler inside thread that have not called looper.prepare ()
What do you mean, subjective understanding, to show a dialog need to have a message loop support, give it a message loop just fine.
But. Here's the problem.
。 What thread does this process take place on? Later debugging found that each binder call came up with a thread, and each time is not the same, it is expected to be taken from a thread pool.
Then how to add Looper to this thread. There is no way to open a thread alone. Sure enough in a thread with Looper to show Dailog seems to be no problem.
So the question comes again, why does showing dialog need Looper support?
Look at the code:
The original dialog has a
Private final Handler Mhandler = new Handler ();
Another
Mlistenershandler = new Listenershandler (this);
It looks like these two handler are all on the current thread. That makes clear why show dialog must be Looper.
Finally another problem, always said that the UI operation must be in the main thread, the above mentioned situation is a bit strange. Show service is remote, display dialog is a sub-thread of service, with the main thread has a half-dime relationship? Puzzling, to my own understanding. This non-main thread does not operate the UI and does not seem to be absolute.
Think carefully, before you see, in fact, whether dialog or acitivty is essentially through the WindowManager to the window to add a view (Viewroot), all the view can not be just a client. Each client has a slice of the window. It's not surprising that there are multiple threads that are going to update their view. Just the view itself can only have one thread to manipulate. This is my understanding that the non-main thread cannot manipulate the UI, and I don't know if it is correct.
Copyright notice: This article Bo Master original articles, blogs, without consent may not be reproduced.
Android cannot manipulate UI awareness on non-main thread