Práctica recomendada para mostrar mensajes de error
¿Cuál es la mejor manera de mostrar mensajes de error al usuario?
Supongamos que el siguiente escenario (por ejemplo, esta pregunta se refiere a un problema común, cuando se puede producir un error en el servicio, en el subproceso, etc.):
- Cargamos algunos datos para alguna pantalla
- Se produce un error (Internet no está disponible, excepción de servidor, otras excepciones …)
¿Cómo mostrar el error? Soluciones posibles:
- Mostrar tostadas – la forma más sencilla, pero no es la mejor (para muchos errores vamos a ver muchos brindis, incluso si la aplicación funciona en el fondo)
- Mostrar error en algún lugar de la pantalla (por ejemplo, gmail muestra 'Sin conexión' en la parte inferior de la lista y propone volver a intentarlo)
¿Cuál es su experiencia? ¿Cómo se muestran los errores de los usuarios? ¿Hay algunas guías que explican cuál es la mejor manera?
He utilizado el alertDialog .. remítase a las imágenes. Futher google
Para el usuario Atención.
Para el formulario Validación editar textos use editText.setError("Your error message") método
Falló la conexión a Internet
Para la conexión interna falló con reintento.
Actualización 1
Para mostrar algún auto terminate información / mensaje utilizamos Toast por ejemplo notificando a un usuario que su Email was sent Successfully. Podemos usar tostadas como a continuación
Toast.makeText (contexto, "El correo electrónico se envió con éxito.", Duración) .show ()
Nota: El usuario no puede interactuar con la tostada predeterminada, Véase también Disposición de tostadas personalizadas
Otra opción es usar la nueva Snackbar
Esperamos que esto sea útil
Depende de la aplicación, y lo que la aplicación será capaz de hacer una vez que ha cumplido este error.
Los dos métodos que Google sugiere en la Guía de diseño de materiales para tratar estos tipos de mensajes son:
Cuadros de diálogo (en este caso el Diálogo Alerta):
Y Snackbars :
Para utilizar su ejemplo: Algunos datos se solicitan desde un servidor remoto, pero debido a algún error o excepción, la recuperación falla y no se devuelve ningún dato.
En este punto, el tipo de mensaje de error dependerá de cómo la aplicación funcionará desde ese punto, sin esos datos. Si la aplicación se realizará tal como es, lo que significa que la búsqueda era algo similar a una actualización de fondo, lo apropiado para mostrar sería una Snackbar. ¿Por qué?
De la Guía:
Las Snackbars proporcionan retroalimentación ligera sobre una operación mostrando un breve mensaje en la parte inferior de la pantalla. Snackbars puede contener una acción.
Peso ligero es realmente la razón aquí. Si la aplicación funcionará sin la recuperación de datos de fondo, no debe bloquear la interfaz de usuario con un mensaje. Sólo deje que el usuario sepa que las cosas no funcionaron de la manera en que deberían hacerlo para que pueda hacer algo al respecto si se preocupa.
He aquí un ejemplo tomado de la guía :
Para el código: Documentos del desarrollador en Snackbars
Nunca use una tostada. Un brindis es demasiado pequeño, demasiado breve y puede pasar desapercibido. Utilice una Snackbar.
Pero , en el escenario en el que su aplicación no funcionará, o mostrará nada más que una pantalla en blanco sin esos datos, lo correcto sería mostrar un cuadro de diálogo de alerta.
Nadie quiere ver nada más que una pantalla en blanco, y si no puede llenarlo con datos, debe darle al usuario una pantalla desde la que puedan realizar funciones alternativas, incluso si es para salir de la aplicación.
De la Guía de Alertas:
Las alertas informan al usuario sobre una situación o acción que requiere su confirmación o confirmación antes de continuar. Difieren ligeramente en aspecto basado en la severidad y el impacto del mensaje transmitido.
Las alertas son interruptivas, urgentes y evitan que los usuarios continúen hasta que tomen una decisión.
Y
Desambiguación de Snackbars: A diferencia de las Alertas, las Snackbars presentan información o acciones opcionales pero importantes y generalmente aparecen después de una acción. Por ejemplo, use una alerta para confirmar el descarte de un borrador. Utilice un snackbar para presentar una acción de deshacer, ya que la acción es opcional y el usuario puede continuar con su tarea principal sin tomar acción.
Así que si la aplicación no funcionará sin esos datos, vaya con un cuadro de diálogo de alerta .
Cualquier cosa menos un brindis. Echa un vistazo a Croutons: http://android.cyrilmottier.com/?p=773
Yo diría que depende de si su aplicación tiene actualmente una actividad activa visible o no. Si lo hace usted podría utilizar cualquiera de las técnicas ya sugeridas sin confundir al usuario sobre el contexto, etc
Si el error / mensaje se origina desde un código de fondo, por ejemplo, un servicio, y su aplicación no está activa, una notificación es una buena alternativa. También, eche un vistazo a las directrices / patrones descritos en el sitio del desarrollador .