On Mon, Sep 20, 2010 at 9:16 PM, DanH <[email protected]> wrote: > No sort of "wait on event" at all??
None you would want to use for your targeted use case. There are, of course, lots of classes that implement wait logic in java.util.concurrent, such as Semaphore. However, those are for managing thread-based interactions. There is no notion of "I'm going to display a dialog and hold my breath until I turn blue in the face or the user completes the dialog". After all, what you would be blocking is the very UI thread that is supposed to be handling the dialog -- meaning that even if you were successful in blocking, your reward would be a broken dialog and ANR result. Assuming for an instant that a three-dialog setup would be a good UI choice (versus, say, a dialog-themed activity implementing a three-stage wizard), you could always use a state machine to keep your code relatively contiguous. The OK button handler of each dialog would tell the state machine to advance, and all your decision making (and, done right, handling of the dialog results) would be in the state machine. In this case, I'd use the dialog-themed three-pane wizard activity, but that's just me. -- 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 [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
