显示错误消息的最佳实践

Question

What is the best way of displaying error messages to the user?

Assume the following scenario (just for example, this question relates to common problem, when error may occur in service, in the thread etc.):

1. We load some data for some screen
2. Error occurs (Internet is not available, server exception, other exceptions ...)

How to show the error? Possible solutions:

1. Show toasts - the simplest way but it is not the best (for many errors we'll see many toasts, even if the application works in the background)
2. Show error somewhere in the screen (eg gmail shows 'No connection' at the bottom of the list and proposes to retry)

What is your experience? How do you show user errors? Is there some guides explaining what is the best way?

Answer 1

I have used the alertDialog.. refer the Images. futher google it

For user Attention.

for form Validation edit texts use editText.setError("Your error message") method

for internet connection failed

for internent connection failed with retry.

Update 1

For showing some auto terminate info/message we use Toast for example notifying a user that your Email was sent Successfully. We can Use Toast like below

Toast.makeText(context, "Email was sent Successfully.", duration).show()

Note: User can't interact with Default toast, See also Custom Toast Layout

Another option is to use the new Snackbar

Hope this will be helpful

Answer 2

It depends on the app, and what the app will be able to do once it has met this error.

The two methods that Google suggests in the Material Design Guide to deal with these types of messages are:

Dialogs (in this case the Alert Dialog):

and Snackbars :

To use your example: Some data is requested from a remote server, but because of some error or exception, the fetch fails and no data is returned.

At this point, the type of error message would depend on how the app will function from that point on, without that data. If the app will perform as it is, meaning the fetch was something akin to a background update, the appropriate thing to show would be a Snackbar. Why?

From the Guide:

Snackbars provide lightweight feedback about an operation by showing a brief message at the bottom of the screen. Snackbars can contain an action.

Lightweight is really the reason here. If the app will function without that background data fetch, you should not block the UI with a message. Just let the user know things didn't work out the way they should so that he can do something about it if he cares.

Here is an example taken from the guide :

For code: the Developer Docs on Snackbars

Never use a Toast. A Toast is too small, too brief and can go by unnoticed. Use a Snackbar.

But , in the scenario where your app will not function, or will show nothing but a blank screen without that data, the correct thing to do would be to show an Alert Dialog.

No one wants to see nothing but a blank screen, and if you can't populate it with data, you need to give the user a screen from which they can perform alternate functions, even if that is to quit the app.

From the Guide on Alerts:

Alerts inform the user about a situation or action that requires their confirmation or acknowledgement before proceeding. They differ slightly in appearance based upon the severity and impact of the message conveyed.

Alerts are interruptive, urgent, and prevent users from proceeding until they make a decision.

AND

Disambiguation from Snackbars: In contrast to Alerts, Snackbars present optional but important information or actions and usually appear after an action. For example, use an alert to confirm discarding a draft. Use a snackbar to present an undo action, because the action is optional and the user can continue with their primary task without taking action.

So if the app won't function without that data, go with an Alert Dialog .

Answer 3

Anything but a Toast. Check out Croutons: http://android.cyrilmottier.com/?p=773

Answer 4

I would say that it depends on wether your application currently has a visible active activity or not. If it does you could use any of the techniques already suggested without confusing the user about context etc.

If the error/message originates from background code eg a service, and your application isn't active, a notification is a good alternative. Also, take a look at the guidelines/patterns described on the developer site.