Snackbar: The appropriate interruption

Alerts are pretty critical for communicating with your user. But it helps to know what is appropriate so that your users don’t hate you. Fortunately, there’s a simple answer: use a Snackbar!

But, for those nuanced cases where you want to choose between a Toast and a Snackbar, the design docs have pretty much every detail you could need. And if you really like being wrong, there’s always a Dialog! I know you’re better than that, but I’ll walk you through each of these options anyway. (I’m nice like that.)

Dialog

A Dialog presents information to the user that they must then act on. This is horribly disruptive, which means it’s the perfect choice when you need to interrupt the user. If you have an urgent message that requires an immediate answer from the user, then the Dialog is the right choice.

A dialog can present the user with a small amount of information (generally 2 sentences or less), and two actions. The Dialog takes over the screen, moving the app activity back a level, because the assumption is that whatever comes next in the activity is dependent on the answer that the user gives.

Because the user can’t do anything until they answer your question, you want to be very careful about how you use a dialog. By which I really mean, use dialogs sparingly.

But when you are creating your Dialog, the first thing you’ll want to do is wrap it in an AppCompatDialogFragment. Doing so will make it much easier for you to construct a dialog, pass information back based on the values the user chooses, and really control that custom dialog experience that I’m not going to explain right now.

Then, for an AlertDialog, which is what we’re talking about today, you’ll need a message and your buttons. AlertDialogs can offer up to three buttons: a positive choice (to agree to whatever the question is), a negative choice (maybe a cancel), and a neutral option (like a remind-me-later).

public class DiscardDialogFragment extends AppCompatDialogFragment {
  Override
  public Dialog onCreateDialog(Bundle savedInstanceState) {
    AlertDialog.Builder builder =
        new AlertDialog.Builder(getActivity());
    builder.setMessage("Discard draft?")
        .setPositiveButton("DISCARD",
            new DialogInterface.OnClickListener() {
              public void onClick(DialogInterface dialog, int id) {
                // Discard that draft!
              }
            })
        .setNegativeButton("CANCEL",
            new DialogInterface.OnClickListener() {
              public void onClick(DialogInterface dialog, int id) {
                // User cancelled the dialog, so IDK, you do you
              }
            });
        // Create the AlertDialog object and return it
        return builder.create();
    }
}

And then you just need to invoke your new DialogFragment!

public void confirmDiscard() {
    DialogFragment newFragment = new DiscardDialogFragment();
    newFragment.show(getSupportFragmentManager(), "discard");
}

Note that I’m not really talking about full-screen dialogs here. Those have a natural home when it comes to getting a bunch of information from the user at once, like with creating a new calendar event. And chooser dialogs appear because the user needs to choose an option, as they should. But keep in mind that these are still interruptive. It’s just so appropriate that you don’t mind the interruption.

Toast

When what you are really trying to do is just give the user a heads-up, a Dialog is clearly overkill. This is probably a situation better suited to a Toast. Toasts are a great way for you to confirm that that thing the user was doing really did happen. Because a toast is a widget developers can pass a short string to, which appears and disappears entirely on its own.

Short, sweet, and information: The Toast

Creating a Toast is incredibly simple: all you need is the context, your String, and an opinion on how long the Toast should linger. Then you build it with makeText(), and display it with show(). Bam.

WordsContext context = getApplicationContext();
CharSequence text = "That thing happened.";
int duration = Toast.LENGTH_SHORT;
Toast toast = Toast.makeText(context, text, duration);
toast.show();

Toasts are clearly very easy to use but, as a developer, you’re limited in what you can do with a Toast. And all you can do is say something simple, generally a confirmation of some event. But what if that event was destructive — like a deletion? Your user might not have meant to do that, and now they are panicking and looking for the undo and wondering why you didn’t double check before deleting that super cute pic! OMG, you are the worst.

This is why Toasts are generally preferred for system-level messages, like announcing the device has been unplugged. And everything you might want to say should be said with a Snackbar.

Snackbar

A Snackbar is similar to a Toast, but is more versatile in that it is interactive — like offering that undo your user is still searching for. A Snackbar animates upward from the bottom of the screen and the user can swipe it away — or not. If they do nothing, it will time out on its own and automatically disappear (like a Toast!).

A confirmation + an optional action: The Snackbar

Thanks to the dedicated efforts of a certain English developer working on the Design Support Library, Snackbars are also super easy to use. Similar to a Toast, there’s a make() and a show(). (Although this time, instead of the Context, you need the View.) And to add that optional action, there’s a setAction(). Super easy. (Thanks, Chris Banes!)

Snackbar snackbar = Snackbar
        .make(currentActivityView, "Archived", Snackbar.LENGTH_SHORT)
        .setAction("UNDO", new View.OnClickListener() {
            @Override
            public void onClick(View view) {
                // Undo the archive.
            }
        });
snackbar.show();

There are some other pretty clever features with Snackbars, such as the setCallback() function, which allows you to receive an update whenever a Snackbar is displayed or dismissed. And, unlike a Toast, you can customize parts of the look of the Snackbar. Which means I wasn’t lying when I said it was better. A Snackbar is less disruptive than a Dialog, and more customizable than a Toast.

What’s next?

Now you have three components that will help you interrupt your users in the perfect way.

• Use a Dialog when the user’s response is critical to your app flow — because you need to be disruptive in these moments.
• But use a Toast to give a user a tidbit of information that doesn’t change anything.
• And for everything in between, the new Snackbar is your best friend.

Have fun in the world of non-disruptive alerts!

#BuildBetterApps

Follow the Android Development Patterns Collection for more!