i never look forward to handling Android dialogs, maybe someone can point me to a better way of doing it than i'm doing right now.
say i have a dialog which has one text field in it, and OK and Cancel buttons. i make the dialog with AlertDialog.Builder, and set click listeners on the buttons and dismiss listener on the dialog.
when the dismiss listener fires, can i tell which button caused the dismiss? i don't see how, so in the click listener, i set a member flag according to which button was clicked. then in the dismiss listener, i then check the flag to see whether to proceed or not. a rather backward process. am i missing something?
the other issue i have with Android's dialogs is that if the contents fail validation and the dialog needs to be re-presented, i have to re-show it in the dismiss listener. in every other environment known to man, dialogs are (somewhat) modal, so the dialog stays up unless expressly dismissed by code. IMHO, the latter makes more sense.
thanks for any help with this stuff,
-- jason.vp.engineering.particle
"when the dismiss listener fires, can i tell which button caused
the dismiss?"
No - I don't think any of the buttons by default cause the dialog to be
dismissed. This happens when you call dismiss() or cancel() on the dialog or
the user presses the back button.
"so in the click listener, i set a member flag according to which button was
clicked. then in the dismiss listener, i then check the flag to see whether
to proceed or not"
But you have set on click listeners for each of the two buttons you have,
no? So why not handle their actions in their respective click listeners?
What are you doing in each of those listeners (I'm going to bet you're
dismissing the dialog after storing the flag...)?
"the other issue i have with Android's dialogs is that if the contents fail
validation and the dialog needs to be re-presented, i have to re-show it in
the dismiss listener"
No, you don't have to do this. In your listener for the OK button you can
get the text field, validate it, and if it fails show a toast message, and
don't dismiss the dialog. If it succeeds, do what you need to with the
entered data and THEN call dismiss() on the dialog.
If you want to get fancy you can also validate the user data as they type
and disable and enable the OK button in response so they can only hit OK
when they've entered valid data.
Also, I highly doubt you need the dismiss listener in your case. Hope that
helps.
--------------------------------------------------------------------------- ----------------------
TreKing - Chicago transit tracking app for Android-powered devices
http://sites.google.com/site/rezmobileapps/treking
jason.android.li...@gmail.com> wrote:
> i never look forward to handling Android dialogs, maybe someone can
> point me to a better way of doing it than i'm doing right now.
> say i have a dialog which has one text field in it, and OK and Cancel
> buttons. i make the dialog with AlertDialog.Builder, and set click
> listeners on the buttons and dismiss listener on the dialog.
> when the dismiss listener fires, can i tell which button caused the
> dismiss? i don't see how, so in the click listener, i set a member
> flag according to which button was clicked. then in the dismiss
> listener, i then check the flag to see whether to proceed or not. a
> rather backward process. am i missing something?
> the other issue i have with Android's dialogs is that if the contents
> fail validation and the dialog needs to be re-presented, i have to
> re-show it in the dismiss listener. in every other environment known
> to man, dialogs are (somewhat) modal, so the dialog stays up unless
> expressly dismissed by code. IMHO, the latter makes more sense.
> thanks for any help with this stuff,
> --
> jason.vp.engineering.particle
> --
> 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<android-developers%2Bunsubs cribe@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
i don't actively dismiss the dialog at any point, therefore something behind the button click must be doing it. i took a look in android.internal.app.AlertController.java, and found that its click listener calls the appropriate button handler, then sends a dismiss message to the dialog. unless i'm missing something big, seems fairly conclusive.
so the reasons why i do it this convoluted way are coming back to me. due to the auto-dismiss, i have to validate in the dismiss handler, as i can't schedule a reappearance of the dialog in the onClick().
i suppose i'll have to get all fancy and do the validation key by key, then.
(the point remains that Android has the weirdest modal dialog handling of any environment i've encountered!)
>"when the dismiss listener fires, can i tell which button caused the dismiss?"
>No - I don't think any of the buttons by default cause the dialog to >be dismissed. This happens when you call dismiss() or cancel() on >the dialog or the user presses the back button.
>"so in the click listener, i set a member flag according to which >button was clicked. then in the dismiss listener, i then check the >flag to see whether to proceed or not"
>But you have set on click listeners for each of the two buttons you >have, no? So why not handle their actions in their respective click >listeners? What are you doing in each of those listeners (I'm going >to bet you're dismissing the dialog after storing the flag...)?
>"the other issue i have with Android's dialogs is that if the >contents fail validation and the dialog needs to be re-presented, i >have to re-show it in the dismiss listener"
>No, you don't have to do this. In your listener for the OK button >you can get the text field, validate it, and if it fails show a >toast message, and don't dismiss the dialog. If it succeeds, do what >you need to with the entered data and THEN call dismiss() on the >dialog.
>If you want to get fancy you can also validate the user data as they >type and disable and enable the OK button in response so they can >only hit OK when they've entered valid data.
>Also, I highly doubt you need the dismiss listener in your case. >Hope that helps.
>On Thu, Nov 19, 2009 at 8:00 PM, Jason Proctor ><<mailto:jason.android.li...@gmail.com>jason.android.li...@gmail.com> >wrote:
>i never look forward to handling Android dialogs, maybe someone can
>point me to a better way of doing it than i'm doing right now.
>say i have a dialog which has one text field in it, and OK and Cancel
>buttons. i make the dialog with AlertDialog.Builder, and set click
>listeners on the buttons and dismiss listener on the dialog.
>when the dismiss listener fires, can i tell which button caused the
>dismiss? i don't see how, so in the click listener, i set a member
>flag according to which button was clicked. then in the dismiss
>listener, i then check the flag to see whether to proceed or not. a
>rather backward process. am i missing something?
>the other issue i have with Android's dialogs is that if the contents
>fail validation and the dialog needs to be re-presented, i have to
>re-show it in the dismiss listener. in every other environment known
>to man, dialogs are (somewhat) modal, so the dialog stays up unless
>expressly dismissed by code. IMHO, the latter makes more sense.
>thanks for any help with this stuff,
>--
>jason.vp.engineering.particle
>--
>You received this message because you are subscribed to the Google
>Groups "Android Developers" group.
>To post to this group, send email to ><mailto:android-developers@googlegroups.com>android-developers@googlegroup s.com
>To unsubscribe from this group, send email to
><mailto:android-developers%2Bunsubscribe@googlegroups.com>android-develope rs+unsubscribe@googlegroups.com
>For more options, visit this group at
><http://groups.google.com/group/android-developers?hl=en>http://groups.google.com/group/android-developers?hl=en
Just ran a quick test on my code and you're right! Sorry for the wrong info.
I've been manually calling dismiss() and cancel() on the dialogs I use. It's
been a while since I looked at that code and figured I was doing that
because I had to ... now this makes me wonder why I did it that way to begin
with =P.
But you should still be able to do validation on the OK button being
clicked, and if that fails, just re-show the dialog.
"as i can't schedule a reappearance of the dialog in the onClick()"
Why not? If you define your click handler inline within the activity that's
using it, you can just call showDialog(ID) in onClick(), no?
Or does that not work?
--------------------------------------------------------------------------- ----------------------
TreKing - Chicago transit tracking app for Android-powered devices
http://sites.google.com/site/rezmobileapps/treking
jason.android.li...@gmail.com> wrote:
> thanks for the response, most helpful.
> i don't actively dismiss the dialog at any point, therefore something
> behind the button click must be doing it. i took a look in
> android.internal.app.AlertController.java, and found that its click
> listener calls the appropriate button handler, then sends a dismiss
> message to the dialog. unless i'm missing something big, seems fairly
> conclusive.
> so the reasons why i do it this convoluted way are coming back to me.
> due to the auto-dismiss, i have to validate in the dismiss handler,
> as i can't schedule a reappearance of the dialog in the onClick().
> i suppose i'll have to get all fancy and do the validation key by key,
> then.
> (the point remains that Android has the weirdest modal dialog
> handling of any environment i've encountered!)
> thanks,
> J
> >"when the dismiss listener fires, can i tell which button caused the
> dismiss?"
> >No - I don't think any of the buttons by default cause the dialog to
> >be dismissed. This happens when you call dismiss() or cancel() on
> >the dialog or the user presses the back button.
> >"so in the click listener, i set a member flag according to which
> >button was clicked. then in the dismiss listener, i then check the
> >flag to see whether to proceed or not"
> >But you have set on click listeners for each of the two buttons you
> >have, no? So why not handle their actions in their respective click
> >listeners? What are you doing in each of those listeners (I'm going
> >to bet you're dismissing the dialog after storing the flag...)?
> >"the other issue i have with Android's dialogs is that if the
> >contents fail validation and the dialog needs to be re-presented, i
> >have to re-show it in the dismiss listener"
> >No, you don't have to do this. In your listener for the OK button
> >you can get the text field, validate it, and if it fails show a
> >toast message, and don't dismiss the dialog. If it succeeds, do what
> >you need to with the entered data and THEN call dismiss() on the
> >dialog.
> >If you want to get fancy you can also validate the user data as they
> >type and disable and enable the OK button in response so they can
> >only hit OK when they've entered valid data.
> >Also, I highly doubt you need the dismiss listener in your case.
> >Hope that helps.
> >On Thu, Nov 19, 2009 at 8:00 PM, Jason Proctor
> ><<mailto:jason.android.li...@gmail.com>jason.android.li...@gmail.com>
> >wrote:
> >i never look forward to handling Android dialogs, maybe someone can
> >point me to a better way of doing it than i'm doing right now.
> >say i have a dialog which has one text field in it, and OK and Cancel
> >buttons. i make the dialog with AlertDialog.Builder, and set click
> >listeners on the buttons and dismiss listener on the dialog.
> >when the dismiss listener fires, can i tell which button caused the
> >dismiss? i don't see how, so in the click listener, i set a member
> >flag according to which button was clicked. then in the dismiss
> >listener, i then check the flag to see whether to proceed or not. a
> >rather backward process. am i missing something?
> >the other issue i have with Android's dialogs is that if the contents
> >fail validation and the dialog needs to be re-presented, i have to
> >re-show it in the dismiss listener. in every other environment known
> >to man, dialogs are (somewhat) modal, so the dialog stays up unless
> >expressly dismissed by code. IMHO, the latter makes more sense.
> >thanks for any help with this stuff,
> >--
> >jason.vp.engineering.particle
> >--
> >You received this message because you are subscribed to the Google
> >Groups "Android Developers" group.
> >To post to this group, send email to
> ><mailto:android-developers@googlegroups.com>
> android-developers@googlegroups.com
> >To unsubscribe from this group, send email to
> ><mailto:android-developers%2Bunsubscribe@googlegroups.com<android-develope rs%252Bunsubscribe@googlegroups.com>
> >android-developers+unsubscribe@googlegroups.com<android-developers%2Bunsub scribe@googlegroups.com>
> >For more options, visit this group at
> ><http://groups.google.com/group/android-developers?hl=en>
> http://groups.google.com/group/android-developers?hl=en
> >--
> >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<android-developers%2Bunsub scribe@googlegroups.com>
> >For more options, visit this group at
> ><http://groups.google.com/group/android-developers?hl=en>
> http://groups.google.com/group/android-developers?hl=en
> --
> jason.vp.engineering.particle
> --
> 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<android-developers%2Bunsubs cribe@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
>Just ran a quick test on my code and you're right! Sorry for the >wrong info. I've been manually calling dismiss() and cancel() on the >dialogs I use. It's been a while since I looked at that code and >figured I was doing that because I had to ... now this makes me >wonder why I did it that way to begin with =P.
>But you should still be able to do validation on the OK button being >clicked, and if that fails, just re-show the dialog.
>"as i can't schedule a reappearance of the dialog in the onClick()"
>Why not? If you define your click handler inline within the activity >that's using it, you can just call showDialog(ID) in onClick(), no?
>Or does that not work?
>On Fri, Nov 20, 2009 at 1:20 PM, Jason Proctor ><<mailto:jason.android.li...@gmail.com>jason.android.li...@gmail.com> >wrote:
>thanks for the response, most helpful.
>i don't actively dismiss the dialog at any point, therefore something
>behind the button click must be doing it. i took a look in
>android.internal.app.AlertController.java, and found that its click
>listener calls the appropriate button handler, then sends a dismiss
>message to the dialog. unless i'm missing something big, seems fairly
>conclusive.
>so the reasons why i do it this convoluted way are coming back to me.
>due to the auto-dismiss, i have to validate in the dismiss handler,
>as i can't schedule a reappearance of the dialog in the onClick().
>i suppose i'll have to get all fancy and do the validation key by key, then.
>(the point remains that Android has the weirdest modal dialog
>handling of any environment i've encountered!)
>thanks,
>J
>>"when the dismiss listener fires, can i tell which button caused >>the dismiss?"
>>No - I don't think any of the buttons by default cause the dialog to
>>be dismissed. This happens when you call dismiss() or cancel() on
>>the dialog or the user presses the back button.
>>"so in the click listener, i set a member flag according to which
>>button was clicked. then in the dismiss listener, i then check the
>>flag to see whether to proceed or not"
>>But you have set on click listeners for each of the two buttons you
>>have, no? So why not handle their actions in their respective click
>>listeners? What are you doing in each of those listeners (I'm going
>>to bet you're dismissing the dialog after storing the flag...)?
>>"the other issue i have with Android's dialogs is that if the
>>contents fail validation and the dialog needs to be re-presented, i
>>have to re-show it in the dismiss listener"
>>No, you don't have to do this. In your listener for the OK button
>>you can get the text field, validate it, and if it fails show a
>>toast message, and don't dismiss the dialog. If it succeeds, do what
>>you need to with the entered data and THEN call dismiss() on the
>>dialog.
>>If you want to get fancy you can also validate the user data as they
>>type and disable and enable the OK button in response so they can
>>only hit OK when they've entered valid data.
>>Also, I highly doubt you need the dismiss listener in your case.
>>Hope that helps.
>>------------------------------------------------------------------------- ------------------------
>>TreKing - Chicago transit tracking app for Android-powered devices
>>i never look forward to handling Android dialogs, maybe someone can
>>point me to a better way of doing it than i'm doing right now.
>>say i have a dialog which has one text field in it, and OK and Cancel
>>buttons. i make the dialog with AlertDialog.Builder, and set click
>>listeners on the buttons and dismiss listener on the dialog.
>>when the dismiss listener fires, can i tell which button caused the
>>dismiss? i don't see how, so in the click listener, i set a member
>>flag according to which button was clicked. then in the dismiss
>>listener, i then check the flag to see whether to proceed or not. a
>>rather backward process. am i missing something?
>>the other issue i have with Android's dialogs is that if the contents
>>fail validation and the dialog needs to be re-presented, i have to
>>re-show it in the dismiss listener. in every other environment known
>>to man, dialogs are (somewhat) modal, so the dialog stays up unless
>>expressly dismissed by code. IMHO, the latter makes more sense.
>>thanks for any help with this stuff,
>>--
>>jason.vp.engineering.particle
>>--
>>You received this message because you are subscribed to the Google
>>Groups "Android Developers" group.
>>To post to this group, send email to
>>--
>>You received this message because you are subscribed to the Google
>>Groups "Android Developers" group.
>>To post to this group, send email to >><mailto:android-developers@googlegroups.com>android-developers@googlegrou ps.com
>>To unsubscribe from this group, send email to
>><mailto:android-developers%2Bunsubscribe@googlegroups.com>android-develop ers+unsubscribe@googlegroups.com
>>For more options, visit this group at
>--
>You received this message because you are subscribed to the Google
>Groups "Android Developers" group.
>To post to this group, send email to ><mailto:android-developers@googlegroups.com>android-developers@googlegroup s.com
>To unsubscribe from this group, send email to
><mailto:android-developers%2Bunsubscribe@googlegroups.com>android-develope rs+unsubscribe@googlegroups.com
>For more options, visit this group at
><http://groups.google.com/group/android-developers?hl=en>http://groups.google.com/group/android-developers?hl=en
jason.android.li...@gmail.com> wrote:
> can't re-show the dialog in onClick(), because it's already shown. at
> least that was true with 1.1, i should check it with a later SDK.
> so either i do my validation in onDismiss(), or i get all fancy.
> >Just ran a quick test on my code and you're right! Sorry for the
> >wrong info. I've been manually calling dismiss() and cancel() on the
> >dialogs I use. It's been a while since I looked at that code and
> >figured I was doing that because I had to ... now this makes me
> >wonder why I did it that way to begin with =P.
> >But you should still be able to do validation on the OK button being
> >clicked, and if that fails, just re-show the dialog.
> >"as i can't schedule a reappearance of the dialog in the onClick()"
> >Why not? If you define your click handler inline within the activity
> >that's using it, you can just call showDialog(ID) in onClick(), no?
> >Or does that not work?
> >On Fri, Nov 20, 2009 at 1:20 PM, Jason Proctor
> ><<mailto:jason.android.li...@gmail.com>jason.android.li...@gmail.com>
> >wrote:
> >thanks for the response, most helpful.
> >i don't actively dismiss the dialog at any point, therefore something
> >behind the button click must be doing it. i took a look in
> >android.internal.app.AlertController.java, and found that its click
> >listener calls the appropriate button handler, then sends a dismiss
> >message to the dialog. unless i'm missing something big, seems fairly
> >conclusive.
> >so the reasons why i do it this convoluted way are coming back to me.
> >due to the auto-dismiss, i have to validate in the dismiss handler,
> >as i can't schedule a reappearance of the dialog in the onClick().
> >i suppose i'll have to get all fancy and do the validation key by key,
> then.
> >(the point remains that Android has the weirdest modal dialog
> >handling of any environment i've encountered!)
> >thanks,
> >J
> >>"when the dismiss listener fires, can i tell which button caused
> >>the dismiss?"
> >>No - I don't think any of the buttons by default cause the dialog to
> >>be dismissed. This happens when you call dismiss() or cancel() on
> >>the dialog or the user presses the back button.
> >>"so in the click listener, i set a member flag according to which
> >>button was clicked. then in the dismiss listener, i then check the
> >>flag to see whether to proceed or not"
> >>But you have set on click listeners for each of the two buttons you
> >>have, no? So why not handle their actions in their respective click
> >>listeners? What are you doing in each of those listeners (I'm going
> >>to bet you're dismissing the dialog after storing the flag...)?
> >>"the other issue i have with Android's dialogs is that if the
> >>contents fail validation and the dialog needs to be re-presented, i
> >>have to re-show it in the dismiss listener"
> >>No, you don't have to do this. In your listener for the OK button
> >>you can get the text field, validate it, and if it fails show a
> >>toast message, and don't dismiss the dialog. If it succeeds, do what
> >>you need to with the entered data and THEN call dismiss() on the
> >>dialog.
> >>If you want to get fancy you can also validate the user data as they
> >>type and disable and enable the OK button in response so they can
> >>only hit OK when they've entered valid data.
> >>Also, I highly doubt you need the dismiss listener in your case.
> >>Hope that helps.
> >>------------------------------------------------------------------------- ------------------------
> >>TreKing - Chicago transit tracking app for Android-powered devices
> >>i never look forward to handling Android dialogs, maybe someone can
> >>point me to a better way of doing it than i'm doing right now.
> >>say i have a dialog which has one text field in it, and OK and Cancel
> >>buttons. i make the dialog with AlertDialog.Builder, and set click
> >>listeners on the buttons and dismiss listener on the dialog.
> >>when the dismiss listener fires, can i tell which button caused the
> >>dismiss? i don't see how, so in the click listener, i set a member
> >>flag according to which button was clicked. then in the dismiss
> >>listener, i then check the flag to see whether to proceed or not. a
> >>rather backward process. am i missing something?
> >>the other issue i have with Android's dialogs is that if the contents
> >>fail validation and the dialog needs to be re-presented, i have to
> >>re-show it in the dismiss listener. in every other environment known
> >>to man, dialogs are (somewhat) modal, so the dialog stays up unless
> >>expressly dismissed by code. IMHO, the latter makes more sense.
> >>thanks for any help with this stuff,
> >>--
> >>jason.vp.engineering.particle
> >>--
> >>You received this message because you are subscribed to the Google
> >>Groups "Android Developers" group.
> >>To post to this group, send email to
> >>--
> >>You received this message because you are subscribed to the Google
> >>Groups "Android Developers" group.
> >>To post to this group, send email to
> >><mailto:android-developers@googlegroups.com>
> android-developers@googlegroups.com
> >>To unsubscribe from this group, send email to
> >><mailto:android-developers%2Bunsubscribe@googlegroups.com<android-develop ers%252Bunsubscribe@googlegroups.com>
> >android-developers+unsubscribe@googlegroups.com<android-developers%2Bunsub scribe@googlegroups.com>
> >>For more options, visit this group at
> >--
> >You received this message because you are subscribed to the Google
> >Groups "Android Developers" group.
> >To post to this group, send email to
> ><mailto:android-developers@googlegroups.com>
> android-developers@googlegroups.com
> >To unsubscribe from this group, send email to
> ><mailto:android-developers%2Bunsubscribe@googlegroups.com<android-develope rs%252Bunsubscribe@googlegroups.com>
> >android-developers+unsubscribe@googlegroups.com<android-developers%2Bunsub scribe@googlegroups.com>
> >For more options, visit this group at
> ><http://groups.google.com/group/android-developers?hl=en>
> http://groups.google.com/group/android-developers?hl=en
> >--
> >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<android-developers%2Bunsub scribe@googlegroups.com>
> >For more options, visit this group at
> ><http://groups.google.com/group/android-developers?hl=en>
> http://groups.google.com/group/android-developers?hl=en
> --
> jason.vp.engineering.particle
> --
> 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<android-developers%2Bunsubs cribe@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
Jason Proctor wrote:
> can't re-show the dialog in onClick(), because it's already shown. at > least that was true with 1.1, i should check it with a later SDK.
> so either i do my validation in onDismiss(), or i get all fancy.
>> Just ran a quick test on my code and you're right! Sorry for the >> wrong info. I've been manually calling dismiss() and cancel() on the >> dialogs I use. It's been a while since I looked at that code and >> figured I was doing that because I had to ... now this makes me >> wonder why I did it that way to begin with =P.
>> But you should still be able to do validation on the OK button being >> clicked, and if that fails, just re-show the dialog.
>> "as i can't schedule a reappearance of the dialog in the onClick()"
>> Why not? If you define your click handler inline within the activity >> that's using it, you can just call showDialog(ID) in onClick(), no?
>> Or does that not work?
>> On Fri, Nov 20, 2009 at 1:20 PM, Jason Proctor >> <<mailto:jason.android.li...@gmail.com>jason.android.li...@gmail.com> >> wrote:
>> thanks for the response, most helpful.
>> i don't actively dismiss the dialog at any point, therefore something
>> behind the button click must be doing it. i took a look in
>> android.internal.app.AlertController.java, and found that its click
>> listener calls the appropriate button handler, then sends a dismiss
>> message to the dialog. unless i'm missing something big, seems fairly
>> conclusive.
>> so the reasons why i do it this convoluted way are coming back to me.
>> due to the auto-dismiss, i have to validate in the dismiss handler,
>> as i can't schedule a reappearance of the dialog in the onClick().
>> i suppose i'll have to get all fancy and do the validation key by key, then.
>> (the point remains that Android has the weirdest modal dialog
>> handling of any environment i've encountered!)
>> thanks,
>> J
>>> "when the dismiss listener fires, can i tell which button caused >>> the dismiss?"
>>> No - I don't think any of the buttons by default cause the dialog to
>>> be dismissed. This happens when you call dismiss() or cancel() on
>>> the dialog or the user presses the back button.
>>> "so in the click listener, i set a member flag according to which
>>> button was clicked. then in the dismiss listener, i then check the
>>> flag to see whether to proceed or not"
>>> But you have set on click listeners for each of the two buttons you
>>> have, no? So why not handle their actions in their respective click
>>> listeners? What are you doing in each of those listeners (I'm going
>>> to bet you're dismissing the dialog after storing the flag...)?
>>> "the other issue i have with Android's dialogs is that if the
>>> contents fail validation and the dialog needs to be re-presented, i
>>> have to re-show it in the dismiss listener"
>>> No, you don't have to do this. In your listener for the OK button
>>> you can get the text field, validate it, and if it fails show a
>>> toast message, and don't dismiss the dialog. If it succeeds, do what
>>> you need to with the entered data and THEN call dismiss() on the
>>> dialog.
>>> If you want to get fancy you can also validate the user data as they
>>> type and disable and enable the OK button in response so they can
>>> only hit OK when they've entered valid data.
>>> Also, I highly doubt you need the dismiss listener in your case.
>>> Hope that helps.
>>> --------------------------------------------------------------------------- ----------------------
>>> TreKing - Chicago transit tracking app for Android-powered devices
>>> i never look forward to handling Android dialogs, maybe someone can
>>> point me to a better way of doing it than i'm doing right now.
>>> say i have a dialog which has one text field in it, and OK and Cancel
>>> buttons. i make the dialog with AlertDialog.Builder, and set click
>>> listeners on the buttons and dismiss listener on the dialog.
>>> when the dismiss listener fires, can i tell which button caused the
>>> dismiss? i don't see how, so in the click listener, i set a member
>>> flag according to which button was clicked. then in the dismiss
>>> listener, i then check the flag to see whether to proceed or not. a
>>> rather backward process. am i missing something?
>>> the other issue i have with Android's dialogs is that if the contents
>>> fail validation and the dialog needs to be re-presented, i have to
>>> re-show it in the dismiss listener. in every other environment known
>>> to man, dialogs are (somewhat) modal, so the dialog stays up unless
>>> expressly dismissed by code. IMHO, the latter makes more sense.
>>> thanks for any help with this stuff,
>>> --
>>> jason.vp.engineering.particle
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Android Developers" group.
>>> To post to this group, send email to
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Android Developers" group.
>>> To post to this group, send email to >>> <mailto:android-developers@googlegroups.com>android-developers@googlegroups .com
>>> To unsubscribe from this group, send email to
>>> <mailto:android-developers%2Bunsubscribe@googlegroups.com>android-developer s+unsubscribe@googlegroups.com
>>> For more options, visit this group at
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Android Developers" group.
>> To post to this group, send email to >> <mailto:android-developers@googlegroups.com>android-developers@googlegroups .com
>> To unsubscribe from this group, send email to
>> <mailto:android-developers%2Bunsubscribe@googlegroups.com>android-developer s+unsubscribe@googlegroups.com
>> For more options, visit this group at
>> <http://groups.google.com/group/android-developers?hl=en>http://groups.google.com/group/android-developers?hl=en
>> --
>> 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>http://groups.google.com/group/android-developers?hl=en
according to the docs, setCancelable() determines whether the "back" key cancels the dialog.
it's not so much the cancel behaviour as the ok behaviour. if the dialog didn't auto-dismiss on an OK click, then things would work a lot easier.
well, i'm just going to write a wrapper class that does all this dumb stuff and calls out to custom validator and acceptor listeners to do the necessary. it's a bit odd that Android has listeners up the wazoo but Dialog doesn't quite fit in.
>On Fri, Nov 20, 2009 at 1:49 PM, Jason Proctor ><<mailto:jason.android.li...@gmail.com>jason.android.li...@gmail.com> >wrote:
>can't re-show the dialog in onClick(), because it's already shown. at
>least that was true with 1.1, i should check it with a later SDK.
>so either i do my validation in onDismiss(), or i get all fancy.
>>Just ran a quick test on my code and you're right! Sorry for the
>>wrong info. I've been manually calling dismiss() and cancel() on the
>>dialogs I use. It's been a while since I looked at that code and
>>figured I was doing that because I had to ... now this makes me
>>wonder why I did it that way to begin with =P.
>>But you should still be able to do validation on the OK button being
>>clicked, and if that fails, just re-show the dialog.
>>"as i can't schedule a reappearance of the dialog in the onClick()"
>>Why not? If you define your click handler inline within the activity
>>that's using it, you can just call showDialog(ID) in onClick(), no?
>>Or does that not work?
>>------------------------------------------------------------------------- ------------------------
>>TreKing - Chicago transit tracking app for Android-powered devices
>>i don't actively dismiss the dialog at any point, therefore something
>>behind the button click must be doing it. i took a look in
>>android.internal.app.AlertController.java, and found that its click
>>listener calls the appropriate button handler, then sends a dismiss
>>message to the dialog. unless i'm missing something big, seems fairly
>>conclusive.
>>so the reasons why i do it this convoluted way are coming back to me.
>>due to the auto-dismiss, i have to validate in the dismiss handler,
>>as i can't schedule a reappearance of the dialog in the onClick().
>>i suppose i'll have to get all fancy and do the validation key by key, then.
>>(the point remains that Android has the weirdest modal dialog
>>handling of any environment i've encountered!)
>>thanks,
>>J
>>>"when the dismiss listener fires, can i tell which button caused
>>>the dismiss?"
>>>No - I don't think any of the buttons by default cause the dialog to
>>>be dismissed. This happens when you call dismiss() or cancel() on
>>>the dialog or the user presses the back button.
>>>"so in the click listener, i set a member flag according to which
>>>button was clicked. then in the dismiss listener, i then check the
>>>flag to see whether to proceed or not"
>>>But you have set on click listeners for each of the two buttons you
> >>have, no? So why not handle their actions in their respective click
>>>listeners? What are you doing in each of those listeners (I'm going
>>>to bet you're dismissing the dialog after storing the flag...)?
>>>"the other issue i have with Android's dialogs is that if the
>>>contents fail validation and the dialog needs to be re-presented, i
>>>have to re-show it in the dismiss listener"
>>>No, you don't have to do this. In your listener for the OK button
>>>you can get the text field, validate it, and if it fails show a
>>>toast message, and don't dismiss the dialog. If it succeeds, do what
>>>you need to with the entered data and THEN call dismiss() on the
>>>dialog.
>>>If you want to get fancy you can also validate the user data as they
>>>type and disable and enable the OK button in response so they can
>>>only hit OK when they've entered valid data.
>>>Also, I highly doubt you need the dismiss listener in your case.
>>>Hope that helps.
>>>------------------------------------------------------------------------ -------------------------
>>>TreKing - Chicago transit tracking app for Android-powered devices
>>>i never look forward to handling Android dialogs, maybe someone can
>>>point me to a better way of doing it than i'm doing right now.
>>>say i have a dialog which has one text field in it, and OK and Cancel
>>>buttons. i make the dialog with AlertDialog.Builder, and set click
>>>listeners on the buttons and dismiss listener on the dialog.
>>>when the dismiss listener fires, can i tell which button caused the
>>>dismiss? i don't see how, so in the click listener, i set a member
>>>flag according to which button was clicked. then in the dismiss
>>>listener, i then check the flag to see whether to proceed or not. a
>>>rather backward process. am i missing something?
>>>the other issue i have with Android's dialogs is that if the contents
>>>fail validation and the dialog needs to be re-presented, i have to
>>>re-show it in the dismiss listener. in every other environment known
>>>to man, dialogs are (somewhat) modal, so the dialog stays up unless
>>>expressly dismissed by code. IMHO, the latter makes more sense.
>>>thanks for any help with this stuff,
>>>--
>>>jason.vp.engineering.particle
>>>--
>>>You received this message because you are subscribed to the Google
>>>Groups "Android Developers" group.
>>>To post to this group, send email to
>>>--
>>>You received this message because you are subscribed to the Google
>>>Groups "Android Developers" group.
>>>To post to this group, send email to
>>><mailto:<mailto:android-developers@googlegroups.com>android-developers@g ooglegroups.com><mailto:android-developers@googlegroups.com>android-develop ers@googlegroups.com
>>>To unsubscribe from this group, send email to
>>><mailto:<mailto:android-developers%252Bunsubscribe@googlegroups.com>andr oid-developers%2Bunsubscribe@googlegroups.com><mailto:android-developers%2B unsubscribe@googlegroups.com>android-developers+unsubscribe@googlegroups.co m
>>>For more options, visit this group at
Yeah, just ran a quick test and setting cancelable to false stills lets the
dialog be dismissed by a button press. Weird. This definitely feels
ass-backwards.
Well, the last thing I can think of is adding your own layout with an OK and
cancel button with Dialog.setView() and handle the clicking on THOSE the way
you wanted to. That should definitely work. And it might be less work than a
full-blown wrapper.
Good luck!
--------------------------------------------------------------------------- ----------------------
TreKing - Chicago transit tracking app for Android-powered devices
http://sites.google.com/site/rezmobileapps/treking
jason.android.li...@gmail.com> wrote:
> according to the docs, setCancelable() determines whether the "back"
> key cancels the dialog.
> it's not so much the cancel behaviour as the ok behaviour. if the
> dialog didn't auto-dismiss on an OK click, then things would work a
> lot easier.
> well, i'm just going to write a wrapper class that does all this dumb
> stuff and calls out to custom validator and acceptor listeners to do
> the necessary. it's a bit odd that Android has listeners up the wazoo
> but Dialog doesn't quite fit in.
> >What if you call setCancelable(false) on the dialog? Will it still
> >auto-dismiss?
> >I would assume not and then you could do what you're trying to do
> >and call cancel() manually when you're done validating.
> >On Fri, Nov 20, 2009 at 1:49 PM, Jason Proctor
> ><<mailto:jason.android.li...@gmail.com>jason.android.li...@gmail.com>
> >wrote:
> >can't re-show the dialog in onClick(), because it's already shown. at
> >least that was true with 1.1, i should check it with a later SDK.
> >so either i do my validation in onDismiss(), or i get all fancy.
> >>Just ran a quick test on my code and you're right! Sorry for the
> >>wrong info. I've been manually calling dismiss() and cancel() on the
> >>dialogs I use. It's been a while since I looked at that code and
> >>figured I was doing that because I had to ... now this makes me
> >>wonder why I did it that way to begin with =P.
> >>But you should still be able to do validation on the OK button being
> >>clicked, and if that fails, just re-show the dialog.
> >>"as i can't schedule a reappearance of the dialog in the onClick()"
> >>Why not? If you define your click handler inline within the activity
> >>that's using it, you can just call showDialog(ID) in onClick(), no?
> >>Or does that not work?
> >>------------------------------------------------------------------------- ------------------------
> >>TreKing - Chicago transit tracking app for Android-powered devices
> >>i don't actively dismiss the dialog at any point, therefore something
> >>behind the button click must be doing it. i took a look in
> >>android.internal.app.AlertController.java, and found that its click
> >>listener calls the appropriate button handler, then sends a dismiss
> >>message to the dialog. unless i'm missing something big, seems fairly
> >>conclusive.
> >>so the reasons why i do it this convoluted way are coming back to me.
> >>due to the auto-dismiss, i have to validate in the dismiss handler,
> >>as i can't schedule a reappearance of the dialog in the onClick().
> >>i suppose i'll have to get all fancy and do the validation key by key,
> then.
> >>(the point remains that Android has the weirdest modal dialog
> >>handling of any environment i've encountered!)
> >>thanks,
> >>J
> >>>"when the dismiss listener fires, can i tell which button caused
> >>>the dismiss?"
> >>>No - I don't think any of the buttons by default cause the dialog to
> >>>be dismissed. This happens when you call dismiss() or cancel() on
> >>>the dialog or the user presses the back button.
> >>>"so in the click listener, i set a member flag according to which
> >>>button was clicked. then in the dismiss listener, i then check the
> >>>flag to see whether to proceed or not"
> >>>But you have set on click listeners for each of the two buttons you
> > >>have, no? So why not handle their actions in their respective click
> >>>listeners? What are you doing in each of those listeners (I'm going
> >>>to bet you're dismissing the dialog after storing the flag...)?
> >>>"the other issue i have with Android's dialogs is that if the
> >>>contents fail validation and the dialog needs to be re-presented, i
> >>>have to re-show it in the dismiss listener"
> >>>No, you don't have to do this. In your listener for the OK button
> >>>you can get the text field, validate it, and if it fails show a
> >>>toast message, and don't dismiss the dialog. If it succeeds, do what
> >>>you need to with the entered data and THEN call dismiss() on the
> >>>dialog.
> >>>If you want to get fancy you can also validate the user data as they
> >>>type and disable and enable the OK button in response so they can
> >>>only hit OK when they've entered valid data.
> >>>Also, I highly doubt you need the dismiss listener in your case.
> >>>Hope that helps.
> >>>------------------------------------------------------------------------ -------------------------
> >>>TreKing - Chicago transit tracking app for Android-powered devices
> >>>i never look forward to handling Android dialogs, maybe someone can
> >>>point me to a better way of doing it than i'm doing right now.
> >>>say i have a dialog which has one text field in it, and OK and Cancel
> >>>buttons. i make the dialog with AlertDialog.Builder, and set click
> >>>listeners on the buttons and dismiss listener on the dialog.
> >>>when the dismiss listener fires, can i tell which button caused the
> >>>dismiss? i don't see how, so in the click listener, i set a member
> >>>flag according to which button was clicked. then in the dismiss
> >>>listener, i then check the flag to see whether to proceed or not. a
> >>>rather backward process. am i missing something?
> >>>the other issue i have with Android's dialogs is that if the contents
> >>>fail validation and the dialog needs to be re-presented, i have to
> >>>re-show it in the dismiss listener. in every other environment known
> >>>to man, dialogs are (somewhat) modal, so the dialog stays up unless
> >>>expressly dismissed by code. IMHO, the latter makes more sense.
> >>>thanks for any help with this stuff,
> >>>--
> >>>jason.vp.engineering.particle
> >>>--
> >>>You received this message because you are subscribed to the Google
> >>>Groups "Android Developers" group.
> >>>To post to this group, send email to
>Yeah, just ran a quick test and setting cancelable to false stills >lets the dialog be dismissed by a button press. Weird. This >definitely feels ass-backwards.
>Well, the last thing I can think of is adding your own layout with >an OK and cancel button with Dialog.setView() and handle the >clicking on THOSE the way you wanted to. That should definitely >work. And it might be less work than a full-blown wrapper.
>On Fri, Nov 20, 2009 at 2:24 PM, Jason Proctor ><<mailto:jason.android.li...@gmail.com>jason.android.li...@gmail.com> >wrote:
>according to the docs, setCancelable() determines whether the "back"
>key cancels the dialog.
>it's not so much the cancel behaviour as the ok behaviour. if the
>dialog didn't auto-dismiss on an OK click, then things would work a
>lot easier.
>well, i'm just going to write a wrapper class that does all this dumb
>stuff and calls out to custom validator and acceptor listeners to do
>the necessary. it's a bit odd that Android has listeners up the wazoo
>but Dialog doesn't quite fit in.
>>What if you call setCancelable(false) on the dialog? Will it still
>>auto-dismiss?
>>I would assume not and then you could do what you're trying to do
>>and call cancel() manually when you're done validating.
>>------------------------------------------------------------------------- ------------------------
>>TreKing - Chicago transit tracking app for Android-powered devices
> >can't re-show the dialog in onClick(), because it's already shown. at
>>least that was true with 1.1, i should check it with a later SDK.
>>so either i do my validation in onDismiss(), or i get all fancy.
>>>Just ran a quick test on my code and you're right! Sorry for the
>>>wrong info. I've been manually calling dismiss() and cancel() on the
>>>dialogs I use. It's been a while since I looked at that code and
>>>figured I was doing that because I had to ... now this makes me
>>>wonder why I did it that way to begin with =P.
>>>But you should still be able to do validation on the OK button being
>>>clicked, and if that fails, just re-show the dialog.
>>>"as i can't schedule a reappearance of the dialog in the onClick()"
>>>Why not? If you define your click handler inline within the activity
>>>that's using it, you can just call showDialog(ID) in onClick(), no?
>>>Or does that not work?
>>>------------------------------------------------------------------------ -------------------------
>>>TreKing - Chicago transit tracking app for Android-powered devices
>>>i don't actively dismiss the dialog at any point, therefore something
>>>behind the button click must be doing it. i took a look in
>>>android.internal.app.AlertController.java, and found that its click
>>>listener calls the appropriate button handler, then sends a dismiss
>>>message to the dialog. unless i'm missing something big, seems fairly
>>>conclusive.
>>>so the reasons why i do it this convoluted way are coming back to me.
>>>due to the auto-dismiss, i have to validate in the dismiss handler,
>>>as i can't schedule a reappearance of the dialog in the onClick().
>>>i suppose i'll have to get all fancy and do the validation key by key, then.
>>>(the point remains that Android has the weirdest modal dialog
>>>handling of any environment i've encountered!)
>>>thanks,
>>>J
>>>>"when the dismiss listener fires, can i tell which button caused
>>>>the dismiss?"
>>>>No - I don't think any of the buttons by default cause the dialog to
>>>>be dismissed. This happens when you call dismiss() or cancel() on
>>>>the dialog or the user presses the back button.
>>>>"so in the click listener, i set a member flag according to which
>>>>button was clicked. then in the dismiss listener, i then check the
>>>>flag to see whether to proceed or not"
>>>>But you have set on click listeners for each of the two buttons you
>> >>have, no? So why not handle their actions in their respective click
>>>>listeners? What are you doing in each of those listeners (I'm going
>>>>to bet you're dismissing the dialog after storing the flag...)?
>>>>"the other issue i have with Android's dialogs is that if the
>>>>contents fail validation and the dialog needs to be re-presented, i
>>>>have to re-show it in the dismiss listener"
>>>>No, you don't have to do this. In your listener for the OK button
>>>>you can get the text field, validate it, and if it fails show a
>>>>toast message, and don't dismiss the dialog. If it succeeds, do what
>>>>you need to with the entered data and THEN call dismiss() on the
>>>>dialog.
>>>>If you want to get fancy you can also validate the user data as they
>>>>type and disable and enable the OK button in response so they can
>>>>only hit OK when they've entered valid data.
>>>>Also, I highly doubt you need the dismiss listener in your case.
>>>>Hope that helps.
>>>>----------------------------------------------------------------------- --------------------------
>>>>TreKing - Chicago transit tracking app for Android-powered devices
> >>>i never look forward to handling Android dialogs, maybe someone can
>>>>point me to a better way of doing it than i'm doing right now.
>>>>say i have a dialog which has one text field in it, and OK and Cancel
>>>>buttons. i make the dialog with AlertDialog.Builder, and set click
>>>>listeners on the buttons and dismiss listener on the dialog.
>>>>when the dismiss listener fires, can i tell which button caused the
>>>>dismiss? i don't see how, so in the click listener, i set a member
>>>>flag according to which button was clicked. then in the dismiss
>>>>listener, i then check the flag to see whether to proceed or not. a
>>>>rather backward process. am i missing something?
>>>>the other issue i have with Android's dialogs is that if the contents
>>>>fail validation and the dialog needs to be re-presented, i have to
>>>>re-show it in the dismiss listener. in every other environment known
>>>>to man, dialogs are (somewhat) modal, so the dialog stays up unless
>>>>expressly dismissed by code. IMHO, the latter makes more sense.
>>>>thanks for any help with this stuff,
>>>>--
>>>>jason.vp.engineering.particle
>>>>--
>>>>You received this message because you are subscribed to the Google
>>>>Groups "Android Developers" group.
>>>>To post to this group, send email to
