I'm looking through the Android UX design docs, and I'm not finding an article for best practices around error handling.

The type of errors I'm concerned with are limited functionality due to no Internet connectivity, etc.

I thought to create a dialog that the user can close (and then be provided with a cached version of the app), but am now thinking it might make more sense to pop up a notification at the top of the app (Android UI Docs). I feel like this might be more in line with Android style guides, but at the same time I'm not sure that it's appropriate.

If anyone knows of any articles, especially from Android, that would be greatly appreciated.

  • IIRC Android's guidelines recommend against persistent notifications. Is this an error that affects an active app/process or something where the user might not know if anything went wrong?
    – Ben Brocka
    Nov 6, 2012 at 19:05
  • The activity would actually impede the user, (for example:) it's an app that relies on internet connectivity, but the plan is to have there be limited functionality still available. So these aren't errors that relate to crashes, or things that don't work, but more related to limited functionality, or some missing information that is wrong on the user's end.
    – NotSimon
    Nov 6, 2012 at 19:08
  • Don't cause them :-) Nov 9, 2014 at 20:34
  • @DannyVarod Wouldn't that be an ideal world
    – NotSimon
    Nov 11, 2014 at 1:55
  • Practically, a general guideline (not Android specific) is if you can try to overcome the error (e.g. retry) do so, if not (or if that fails) try and return state to state prior to error and alert user that the operation failed. Nov 11, 2014 at 11:11

3 Answers 3


You state that your application would have limited functionality, even if this "error" occurs. Thus any over-eager error reporting is likely to interfere with the limited-functionality version of the application, either by obscuring it or by accidentally convincing the user that something went wrong and the app is now non-functional.

I would advise against a notification, notifications are intended for messages that are time-sensitive or otherwise critical.

The user is in your app already, why force them out of the app and into the notification drawer? Rather, display an indicator of some sort on the limited-functionality activity. That way the user is notified of the missing connectivity, but is otherwise able to interact with the application normally. Best yet, the user can monitor the status of the connectivity as it changes, from within the app.

To make this answer more generalisable, I've seen about four error reporting mechanisms in general use, and each has their place:

  • Inline notification within the application: This is great if the user is expected to be interacting with the application while it is in use, that is, the application is not a background service. It is particularly good if the application continues to function despite the error, as the report is hopefully not intrusive and allows the user to monitor the status of the error as they interact with the application.
  • Toast notification: Toasts are temporary notifications, perfect for basic feedback without interrupting the user's interaction or even consuming screen real-estate. They are only useful for feedback if the user is actively interacting with the application, they disappear after a time, and thus are not good for anything but the most minor of errors. Perhaps use them with inline error reporting, to explain the error more fully.
  • Dialog box: These should be used with care, they interrupt the user's interaction and demand attention. They are good for errors that demand user intervention or choice, before the application can continue. If the app can continue safely without the user's intervention, these are likely not the right choice.
  • Notification: These are "out-of-flow" feedback, perfect for feedback that requires time-sensitive intervention or that might occur when the user is not directly interacting with the application. A failed background download is a good example, while it is not time-sensitive, the user needs to be notified of the error and is not likely to be sitting and monitoring the download.
  • I didn't see this before I finalized the doc, but these are pretty much the classifications of errors we ended up going with.
    – NotSimon
    Nov 9, 2012 at 0:49

An Android application that allows offline operation should not present the user with an error when connectivity is unavailable. It should check for an available data connection, and if not available just enter offline mode as a state of the application.

You can add an icon to the action bar to represent offline mode. Clicking the icon could present sub-menu items for attempting to leave offline mode, enter offline mode when online and/or link to a help page explaining offline mode features to the user.

You might find this question is related.



The question is old but the reply should be taken from the new Android Material Desgin guidelines, errors section: http://www.google.com/design/spec/patterns/errors.html

  • Hi Fabien, welcome to SE.UX. Can you expand on your answer to show what you are referring to in the provided link. Don't force the OP to visit the link - instead answer the question and include the link as a reference for further reading. This helps improve the answers here! Nov 9, 2014 at 20:32
  • Also, the link might get outdated. I'll probably update the answer if you elaborate more :)
    – NotSimon
    Nov 11, 2014 at 1:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.