On Mon, Sep 20, 2010 at 9:33 PM, DanH <danhi...@ieee.org> wrote: > Odd, in a true multi-threading environment if one thread waits (using, > say, a wait on semaphore) then others continue executing. So in spite > of the dialog being "asynchronous", it really isn't -- it's just > hijacking the requesting thread?
Not really. Android's UI is message-driven. Your request to display a dialog is put on the message queue. If you allow the main application thread to do its work, it will pop that message off the queue and render the dialog. Further operations (e.g., clicking a button) put other messages on the queue, which are driven by the main application thread. All requests to do things with the UI follow this same post-a-message pattern. It's why you can't do UI operations from background threads (to avoid synchronization overhead for the message queue) and why you really don't want to tie up the main application thread (prevents Android from processing messages on the queue). -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _The Busy Coder's Guide to Android Development_ Version 3.1 Available! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
