Separe un resultado vacío de una solicitud fallida
Imagine una imprenta de Budapest usando una aplicación para coordinar recogidas de paquetes. El personal abre la lista del día elegido. Si falla la consulta, mostrar «No hay recogidas» podría inducir a error. Ese mensaje solo debe aparecer tras obtener correctamente un resultado sin trabajo que coincida con el día y los filtros visibles.
Pida ejemplos separados de carga inicial, lista cargada correctamente, resultado vacío válido y carga fallida. Incluya la fecha seleccionada en la explicación para que el personal compruebe el contexto. Esta imprenta es un ejemplo hipotético.
Conserve información útil indicando su antigüedad
Aquí, la lista existente puede seguir visible durante la actualización si la empresa permite consultar información anterior. Sitúe el mensaje de actualización junto a ella e indique cuándo se comprobó correctamente por última vez. Si falla la actualización, las entradas antiguas no deben presentarse silenciosamente como recién verificadas.
Conservar la lista ayuda a orientarse, pero puede provocar decisiones basadas en condiciones de recogida que han cambiado. Acuerde qué acciones exigen volver a consultar los datos. Si cambia la fecha durante la carga, impida que un resultado tardío del día elegido antes sustituya la vista recién seleccionada.
Ofrezca una recuperación adecuada al fallo
Android distingue estados de carga, contenido y error, y recomienda considerar el tipo de error al reintentar. MDN explica que las respuestas Fetch requieren comprobar su estado: recibir una respuesta no significa necesariamente que la solicitud haya tenido éxito.
Pida al desarrollador que demuestre una conexión interrumpida, un servicio no disponible y una sesión que exige volver a identificarse. Acuerde una acción útil para cada caso: recargar la lista, contactar con la oficina o iniciar sesión. No culpe a la conexión del teléfono si desconoce la causa. Conserve la fecha elegida cuando corresponda.
Acuerde cuándo terminan los intentos automáticos y cómo salir de la pantalla. La recuperación automática reduce pulsaciones durante interrupciones breves; repetir intentos sin un límite claro puede dejar al personal esperando sin saber qué hacer.
Distinga actualizar datos de modificar un registro
Recargar la lista y marcar un paquete como recogido tienen consecuencias distintas. MDN describe la idempotencia como solicitudes repetidas con el mismo efecto previsto en el servidor. Pregunte cómo se trata esa propiedad en la acción de recogida antes de permitir reintentos automáticos.
Durante el ensayo, interrumpa la respuesta después de modificar el registro de recogida. La aplicación debe ayudar a comprobar el resultado registrado sin crear otro evento de recogida. Acuerde cómo llegan a la oficina los casos pendientes y qué referencia de paquete puede utilizarse. Un botón genérico Reintentar no debe ocultar estas responsabilidades distintas.
Revise los estados como una historia breve
Use paquetes ficticios y pida a alguien del personal que explique cada pantalla antes de pulsar nada. Registre los textos confusos junto con los defectos técnicos. Empiece por esta lista:
- Cargue un día con recogidas y otro con un resultado vacío confirmado.
- Provoque un fallo inicial y otro al actualizar una lista ya visible.
- Cambie la fecha durante la carga y compruebe que etiquetas y resultados coincidan.
- Recupere mediante reintento o inicio de sesión y verifique el contexto seleccionado.
- Interrumpa una actualización de recogida y confirme un único evento operativo registrado.