> (to avoid synchronization overhead for the message queue) That's kind of odd -- synchronization between threads takes microseconds (or should) -- far cheaper than even the simplest UI operation.
On Sep 20, 8:51 pm, Mark Murphy <mmur...@commonsware.com> wrote: > 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/commonsguyhttp://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
