> 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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
No comments:
Post a Comment