Dialogs, Modal Dialogs and Blocking

3400 views
Skip to first unread message

Dick Wall

unread,
Nov 19, 2007, 6:11:07 PM11/19/07
to Android Developers
Hi Android Developers

There have been several inquiries about using dialogs from within
Android applications and rather than reply to each of the separate
threads, I am hoping to answer some of the more common questions in
this thread instead.

Modality vs. Blocking

The most common question seems to be around blocking dialogs, i.e.
dialogs that come up and halt the activity that started the dialog
until a response is made by the user. These questions tend to come in
the form of "does Android support modal dialogs?" to which the answer
is yes, but more importantly while the dialogs are modal, they are not
blocking, and this is a critical distinction.

Modal dialogs mean that the user must provide a response before the
activity can continue, however blocking would mean that the calling
activity's user interface thread was also stopped until a response was
given, Android does not support this mode of operation.

The reason is that at any time, the activity UI thread may need to
respond to an external request, some kind of lifecycle event (maybe
for a received call), a handler tick to update something on the UI, or
any number of other events that may occur. This means that while the
dialog can be modal to the application - requiring a response to the
dialog before the application can continue, it cannot be blocking.

This further implies that an activity cannot "wait" for the response
to a dialog, because to do so would block the UI thread. This is the
reason that the API does not have a simple dialog call where you can
ask for a response and wait for that response before continuing.

Instead, you can set listeners for the buttons or cancel operation
being pressed on AlertDialog that will be called back to in your
activity when these buttons are pressed, and you can then take the
appropriate action.


Using AlertDialog

While you can subclass Dialog and create your own dialog layout for
maximum flexibility, if you just need a simple dialog with one or two
buttons, you can use AlertDialog instead. In fact, there is a method
on Activity called showAlert() that makes it easier to use the
AlertDialog in your application. You will still need to define
listeners though to handle the different buttons being pressed, or the
cancel operation (user hits the back button while in the dialog).

Please take a look at the reference documentation for more info on
showAlert() from the ApplicationContext class documentation:

http://code.google.com/android/reference/android/app/ApplicationContext.html

It is apparent to us now that this is a rather under-documented part
of the Android system and we will be improving this in future
releases. We are also now planning a blog post soon that will help
people get to grips with Dialogs.

I hope this helps

Dick

Raul

unread,
Nov 20, 2007, 4:19:36 AM11/20/07
to Android Developers
It seems many don't understand how a modal window works in a windowing
system. It doesn't block the UI thread, only the application workflow.
When calling showModal or however the api is called, the UI thread
will flag the parent window as modal and re-enter the message pump
accepting input events only for the modal window. Thus the main window
seems "blocked" to the naive user, but it will still deliver other
events (such as paint) to it. (If you had thought a little you might
have asked yourself which thread processes the events for the modal
dialog if the UI thread is blocked?). When the modal window is
dismissed, the UI thread will exit the modal event dispatching routine
and return to the caller so the UI thread seems to be "unblocked" for
the naive developer.

I assume Android doesn't support blocking the application workflow
because it is rather workflow-oriented than application-oriented and a
workflow should complete as soon as possible. That's because the OS
might decide to discard your application to claim resources.

So instead of designing our apps to pause the current workflow
waiting for input you should enter into another state (break the
worflow into smaller logical units). For example Android might call
your Activity's onFreeze() telling you the current state should be
saved in order for your app to be paused or even discarded. Now how
would you handle this if in a middle of a workflow?

Mark Micallef

unread,
Nov 27, 2007, 12:14:49 AM11/27/07
to Android Developers
Hi there,

Can we early Android adopters please have a working example of
creating a simple Option A / Option B type of dialog? I beleive that
would be a huge aid to developers.

Right now I'm having quite a bit of difficulty building a simple
dialog to ask the user the choose from two options as the event
handlers don't have visibility to the primitives and objects of the
class in which they reside (which is the class where I want to use the
user's choice), and unfortunately I'm not used to this programming
model.

Thanks!
Mark

On Nov 20, 10:11 am, Dick Wall <dickw...@gmail.com> wrote:
> Hi Android Developers
>
> There have been several inquiries about usingdialogsfrom within
> Android applications and rather than reply to each of the separate
> threads, I am hoping to answer some of the more common questions in
> this thread instead.
>
> Modality vs.Blocking
>
> The most common question seems to be aroundblockingdialogs, i.e.dialogsthat come up and halt the activity that started the dialog
> until a response is made by the user. These questions tend to come in
> the form of "does Android supportmodaldialogs?" to which the answer
> is yes, but more importantly while thedialogsaremodal, they are notblocking, and this is a critical distinction.
>
> Modaldialogsmean that the user must provide a response before the
> activity can continue, howeverblockingwould mean that the calling
> activity's user interface thread was also stopped until a response was
> given, Android does not support this mode of operation.
>
> The reason is that at any time, the activity UI thread may need to
> respond to an external request, some kind of lifecycle event (maybe
> for a received call), a handler tick to update something on the UI, or
> any number of other events that may occur. This means that while the
> dialog can bemodalto the application - requiring a response to the
> dialog before the application can continue, it cannot beblocking.
>
> This further implies that an activity cannot "wait" for the response
> to a dialog, because to do so would block the UI thread. This is the
> reason that the API does not have a simple dialog call where you can
> ask for a response and wait for that response before continuing.
>
> Instead, you can set listeners for the buttons or cancel operation
> being pressed on AlertDialog that will be called back to in your
> activity when these buttons are pressed, and you can then take the
> appropriate action.
>
> Using AlertDialog
>
> While you can subclass Dialog and create your own dialog layout for
> maximum flexibility, if you just need a simple dialog with one or two
> buttons, you can use AlertDialog instead. In fact, there is a method
> on Activity called showAlert() that makes it easier to use the
> AlertDialog in your application. You will still need to define
> listeners though to handle the different buttons being pressed, or the
> cancel operation (user hits the back button while in the dialog).
>
> Please take a look at the reference documentation for more info on
> showAlert() from the ApplicationContext class documentation:
>
> http://code.google.com/android/reference/android/app/ApplicationConte...

dtkurtz

unread,
Dec 1, 2007, 6:14:28 PM12/1/07
to Android Developers
I'm bumping this, since even with this information it doesn't help
explain how to get a dialog to show and stay on top of an activity.
showAlert momentarily displays a dialog on the home screen, but that's
about it. I can't seem to get it to show on top of my content. I don't
mind that it's non-blocking, but if I can't at least keep it displayed
so to get input from the user, then Dialogs are worthless.

dtkurtz

unread,
Dec 1, 2007, 6:45:34 PM12/1/07
to Android Developers
I've noticed that within my activity's onCreate(), onStart(), and
onResume(), if I call showAlert(this ...) or AlertDialog.show(...),
the alert displays on the home screen momentarily before my layout is
displayed. However, if I create a button, and pass an OnClickListener
such as this:

private OnClickListener m_finishCallback = new OnClickListener()
{
public void onClick(View v)
{
AlertDialog.show(v.getContext(), " title", "CharSequence message",
"CharSequence buttonText", true) ;
}
};

Then the dialog appears and stays on top of my activity when the
button is clicked.

How can I get this behavior without having to click a button?

Thanks.

Peter Blazejewicz

unread,
Dec 1, 2007, 8:16:14 PM12/1/07
to Android Developers
hi,

you can construct global objects on activity lifecycle handlers
however you could wait until current view is fully layed out and
focused to show alerts/dialogs:
http://groups.google.com/group/android-developers/msg/20506de81b3776d6
I don't know better solution yet,
regards,
Peter

Luisa Magarian

unread,
Dec 3, 2007, 4:10:45 PM12/3/07
to android-d...@googlegroups.com
Hi dtkurtz,

You can use a Handler to post() a Runnable containing AlertDialog.show(...).
This will defer the execution of the dialog.

Here is more info on using a Handler:
http://code.google.com/android/reference/android/os/Handler.html

Hope that helps,
Luisa

Nanard

unread,
Dec 8, 2007, 9:31:26 AM12/8/07
to Android Developers
I have finaly found a way to know when a Dilog ends.

It's so simple ! No need to messages :-)

1) In you Activity or Dialog (MyActvityOrDialog.java) , you open a new
Dialog with new MyDialog(myActivityOrDialog, context).show();

2) In MyActivityOrDialog.java, you have a public void refresh() method
to refresh UI (list, text,...).

3) In MyDialog.java
3.1) In the constructor, you store in a variable the parent :
myActivityOrDialog
3.2) Before the dismiss() to close the Dialog, you simply set/
update some global variable (in a Global.java class for instance :
available also from MyActivityOrDialog.java)
3.3) call the parent refresh method : myActivityOrDialog.refresh()
3.4) dismiss();

On 3 déc, 22:10, "Luisa Magarian" <magar...@google.com> wrote:
> Hi dtkurtz,
>
> You can use a Handler to post() a Runnable containing AlertDialog.show(...).
> This will defer the execution of thedialog.
>
> Here is more info on using a Handler:http://code.google.com/android/reference/android/os/Handler.html
>
> Hope that helps,
> Luisa
>
> On Dec 2, 2007 12:45 AM, dtkurtz <dtku...@gmail.com> wrote:
>
>
>
> > I've noticed that within my activity's onCreate(), onStart(), and
> > onResume(), if I call showAlert(this ...) or AlertDialog.show(...),
> > the alert displays on the home screen momentarily before my layout is
> > displayed. However, if I create a button, and pass an OnClickListener
> > such as this:
>
> > private OnClickListener m_finishCallback = new OnClickListener()
> > {
> > public void onClick(View v)
> > {
> > AlertDialog.show(v.getContext(), " title", "CharSequencemessage",
> > "CharSequence buttonText", true) ;
> > }
> > };
>
> > Then thedialogappears and stays on top of my activity when the
> > button is clicked.
>
> > How can I get this behavior without having to click a button?
>
> > Thanks.
>
> > On Dec 1, 6:14 pm, dtkurtz <dtku...@gmail.com> wrote:
> > > I'm bumping this, since even with this information it doesn't help
> > > explain how to get adialogto show and stay on top of an activity.
> > > showAlert momentarily displays adialogon the home screen, but that's
> > > about it. I can't seem to get it to show on top of my content. I don't
> > > mind that it's non-blocking, but if I can't at least keep it displayed
> > > so to get input from the user, then Dialogs are worthless.
>
> > > On Nov 27, 12:14 am, Mark Micallef <manicm...@gmail.com> wrote:
>
> > > > Hi there,
>
> > > > Can we early Android adopters please have a working example of
> > > > creating a simple Option A / Option B type ofdialog? I beleive that
> > > > would be a huge aid to developers.
>
> > > > Right now I'm having quite a bit of difficulty building a simple
> > > >dialogto ask the user the choose from two options as the event
> > > > >dialogcan bemodalto the application - requiring a response to the
> > > > >dialogbefore the application can continue, it cannot beblocking.
>
> > > > > This further implies that an activity cannot "wait" for the response
> > > > > to adialog, because to do so would block the UI thread. This is the
> > > > > reason that the API does not have a simpledialogcall where you can
> > > > > ask for a response and wait for that response before continuing.
>
> > > > > Instead, you can set listeners for the buttons or cancel operation
> > > > > being pressed on AlertDialog that will be called back to in your
> > > > > activity when these buttons are pressed, and you can then take the
> > > > > appropriate action.
>
> > > > > Using AlertDialog
>
> > > > > While you can subclassDialogand create your owndialoglayout for
> > > > > maximum flexibility, if you just need a simpledialogwith one or two

Kazar

unread,
Dec 29, 2007, 5:15:58 AM12/29/07
to Android Developers
I was playing around with the Dialog class and it looks like it is a
hybrid between modal and modeless dialogs. Just to reiterate, modal
dialogs prevent their parent windows from receiving focus. All other
events will work on the parent window, but if you click on it, or tab
to it or whatnot it beeps and returns focus to the modal dialog.
Modeless dialogs on the other hand are separate from their parents so
you can gain focus on the parent windows and back to the dialog at
will.

The dialog in Android is modal. Once it is showing, you cannot do
anything to the underlying window. Android doesn't have the concept of
windows and focus on windows so they can't make modeless dialogs. The
hybrid part is that when calling Dialog::show(), you the dialog
doesn't block so the code continues to execute after the show().

90% of the time, I expect people are going to show a dialog based on
an event. It could be a button click, or maybe some internal event. It
isn't a big deal to show the dialog, let the event handler run to
completion and have a handler attached to an OK button that handles
the users input. The other 10%, you will have to send state
information to the dialog so it knows what to do.

Mark Wyszomierski

unread,
Dec 30, 2007, 7:02:52 PM12/30/07
to Android Developers
Does anyone have an example of a dialog using the Dialog class?

Right now I've made a 'dialog' by changing an Activity's theme to
'dialog', which almost works, but there's no way to block the user
from cancelling the dialog by hitting the back button. I want to force
them to make a button choice rather than letting them go back. Is it
possible to do that via an Activity?

Thanks,
Mark

On Dec 29, 5:15 am, Kazar <atyt...@gmail.com> wrote:
> I was playing around with the Dialog class and it looks like it is a
> hybrid between modal and modeless dialogs. Just to reiterate, modal
> dialogs prevent their parent windows from receiving focus. All other
> events will work on the parent window, but if you click on it, or tab
> to it or whatnot it beeps and returns focus to the modal dialog.
> Modeless dialogs on the other hand are separate from their parents so
> you can gain focus on the parent windows and back to the dialog at
> will.
>
> The dialog in Android is modal. Once it is showing, you cannot do
> anything to the underlying window. Android doesn't have the concept of
> windows and focus on windows so they can't make modeless dialogs. The
> hybrid part is that when calling Dialog::show(), you the dialog
> doesn'tblockso the code continues to execute after the show().
Reply all
Reply to author
Forward
0 new messages