Dialogs

If you have used a desktop operating system written in the past 25 years or so, you are used to dialogs (otherwise referred to as “dialog boxes”, “modals”, and “those things that keep getting in the way of what I am trying to do”).

On the whole, mobile design tries to get away from dialogs. Where possible, try not to lock the user into doing one specific thing. So, for example, if you need the user to provide a username and password, rather than use a dialog, consider using a regular activity, or display a panel inside of an existing activity. That way, the user can not only give you those credentials, but the user can get to your help and support screens to learn more about why you are asking for those credentials.

However, Android does support dialogs, for those cases where you need them, and we will explore some options for those in this chapter.

A Tale of Four Dialogs

Android has a tendency of making simple things complicated, and dialogs are no exception. As a result, there are four main ways that you can set up a dialog: Dialog, AlertDialog, DialogFragment, and Theme.AppCompat.Dialog.

Dialog

The base for “true” dialogs in Android is Dialog. This class sets up a window that floats over top of your activity/fragment and displays whatever content you provide.

However, on its own, Dialog itself has no UI. It will display whatever you provide and does not “decorate” that with other elements.

AlertDialog

If you have used Android for a few years, you are probably used to seeing dialogs that are styled like this one:

This stock “look and feel” comes from AlertDialog. AlertDialog is a subclass of Dialog that offers a standard structure, including things like a title and positive (“Nuke It”) and negative (“Um, No”) buttons.

DialogFragment

A Dialog (or AlertDialog) is tied to the activity that displays it. If that activity is destroyed and recreated due to a configuration change, a Dialog will not be re-displayed… at least, not without help.

DialogFragment is a wrapper around Dialog and AlertDialog that will re-display its dialog after a configuration change. Often times, we use DialogFragment so it handles that element of state for us.

There are two main ways of implementing a DialogFragment:

• If you override onCreateView(), like you would in a regular fragment, that UI will be wrapped in a Dialog and that Dialog is what is shown to the user
• Alternatively, if you override onCreateDialog(), you can return your own Dialog, such as an AlertDialog

We will see DialogFragment and onCreateDialog() shortly.

Theme.AppCompat.Dialog

Activities, by default, appear to fill the screen on mobile devices. In reality, they fill their window, and that window happens to mostly fill the screen on mobile devices most of the time. The story starts to get complicated when users go into split-screen mode, or for users using your app on desktop-style environments like Chrome OS, but the concept remains the same.

However, the reason why an activity fills its window, by default, is because that is what its theme says to do.

Not all themes do that. So, while Theme.AppCompat has its activity fill its window, Theme.AppCompat.Dialog does not. Instead, it only takes up whatever space is needed for its content, akin to how wrap_content works with layouts. That content is centered on the screen, and whatever activity is behind this one on the back stack is shown around the edges.

Visually, this appears like a dialog. So, if you find DialogFragment to be too constraining, you are welcome to use themes to have one or more activities appear like floating dialogs.