Interesting thread. I actually want the exact same thing as swapnil kamble, coming from .NET it is very nice to deal with MessageBox.Show. The Android way is actually horrible from where Im standing (even though I really like Android and the framework in general).
I need to not go forward with some code until the users has made its decision. To have to do these very messy workarounds is just too sad = ( But I guess I dont have a choice. Regards, On 4 Jan, 11:51, swapnil kamble <[email protected]> wrote: > Thanks Dianne for your nice explanation. I have used synchronization point > between two threads with a timeout value. Its smoothly working for me. > > Thanks Romain for pointing me to CounterDownLatch. > > > > > > On Sat, Jan 2, 2010 at 2:14 AM, Dianne Hackborn <[email protected]> wrote: > > On Thu, Dec 31, 2009 at 2:39 AM, swapnil kamble > > <[email protected]>wrote: > > >> Have you used MessageBox.show() API in Windows ? If yes then you can > >> understand it easily what I am saying. > > > This is API is not really blocking the thread -- it is running a nested > > event loop, until the user responds to the dialog. This kind of behavior is > > very deliberately not implemented in Android because it results in poor > > application interaction behavior and edge cases, which is especially > > problematic in an environment like a cell phone when an application must > > be interruptible at any time. > > > For example, if your application is sitting there blocking its main thread > > like this, and the user receives an incoming call or handles a notification, > > what do you think should happen? If we try to pause the activity while in > > this state to move on to the next thing, we will end up calling > > Activity.onPause() and all kinds of other questionable stuff while nested > > down inside of your app. Or if you have a broadcast receiver for, say, the > > device going to sleep, this code would end up being called from deep in your > > "blocking" method call. In all of these cases, it is unlikely for the > > application to really expect this to happen. > > > These kinds of nested event loops are just bad news. PalmOS was the king > > example of the horror they cause, but even Windows suffers from it -- all > > those apps that get in weird unresponsive states while waiting on a dialog? > > MessageBox is often to blame. > > > My strong suggestion: re-arrange your code to not do this kind of thing. > > You have some method that needs to get input from the user to return a > > response? Make that method async as well, to return its result in a > > callback, because if it needs to wait for the user then that is truly what > > it is. > > > -- > > Dianne Hackborn > > Android framework engineer > > [email protected] > > > Note: please don't send private questions to me, as I don't have time to > > provide private support, and so won't reply to such e-mails. All such > > questions should be posted on public forums, where I and others can see and > > answer them. > > > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected]<android-developers%2Bunsubs > > [email protected]> > > For more options, visit this group at > >http://groups.google.com/group/android-developers?hl=en > > -- > ...Swapnil > > || Hare Krishna Hare Krishna Krishna Krishna Hare Hare || > || Hare Rama Hare Rama Rama Rama Hare Hare ||
-- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
