Separe copias reemplazables y trabajo original
Imagine un mayorista ficticio de iluminación de Budapest preparando una aplicación para sus comerciales. Un catálogo público descargado, un presupuesto de cliente pendiente y una preferencia de idioma cumplen funciones distintas. El catálogo puede descargarse nuevamente. Un presupuesto redactado solo en el teléfono puede contener trabajo inexistente en otro lugar. Una preferencia aporta comodidad.
Las recomendaciones de Android sobre la capa de datos separan fuentes y definen una fuente de referencia. Conviértalas en un inventario empresarial: propietario de cada elemento, ubicación del registro que prevalece y existencia de otra copia. Pida al desarrollador que identifique expresamente el trabajo guardado solo en el dispositivo.
Dé una vida útil a la información descargada
Para el mayorista, acuerde qué detalles necesita el personal durante las visitas y cuántas imágenes conservar. Guardarlas todas puede mejorar consultas posteriores, pero ocupa más almacenamiento. Una caché menor exige más descargas. Elija un límite y un orden de eliminación según la tarea comercial.
Defina cuándo actualizar los datos de productos y qué decisiones necesitan información actual del servidor. Por ejemplo, podría permitirse consultar una ficha de lámpara descargada, exigiendo una comprobación actual antes de confirmar disponibilidad. Incluya ese límite en las especificaciones. Borrar una imagen antigua no debe eliminar también un presupuesto pendiente.
Adapte la limpieza a cada cuenta y elemento
Firebase documenta que la caché web persistente de Firestore no se vacía automáticamente entre sesiones. Este ejemplo específico de la web justifica verificar el almacenamiento de cada plataforma, sin suponer que cerrar una sesión borra la información guardada.
Acuerde por separado qué ocurre al cerrar sesión con copias del catálogo público, datos de clientes propios de la cuenta y presupuestos sin enviar. Antes de una acción destructiva, explique al comercial qué perdería y qué seguiría siendo recuperable desde otro lugar. Vincule cualquier trabajo pendiente conservado a su cuenta original. La siguiente persona conectada no debe verlo ni enviarlo.
Distinga entre eliminar una copia del dispositivo y borrar el registro empresarial del servidor. Dé nombres claros a esas acciones y demuéstrelas con cuentas ficticias. Una única etiqueta Borrar datos deja demasiado margen para expectativas distintas.
Presupueste los cambios de datos almacenados
La documentación de Room de Android advierte que recurrir a una migración destructiva puede borrar datos de tablas cuando no existe una ruta de migración. Pregunte si la actualización propuesta considera desechable toda la información local o conserva el trabajo original.
Suponga que el mayorista añade el campo nombre de la estancia a los borradores de presupuestos. Acuerde cómo aparece un borrador antiguo tras actualizar, incluso si nunca se recogió ese dato. Reconstruir el catálogo descargado puede ser aceptable; perder silenciosamente el borrador del comercial es otra decisión empresarial. Pida demostrar ambos resultados con un borrador de prueba de la versión anterior.
Apruebe un breve acuerdo de almacenamiento
Guarde estas decisiones junto a las especificaciones funcionales y asigne responsable para cambios futuros. El acuerdo debe explicar qué sobrevive a cada evento antes de elegir detalles de implementación.
- Enumere por separado copias descargadas, borradores originales y preferencias.
- Registre propietario, registro que prevalece y vía de recuperación disponible.
- Fije límites de descarga, reglas de actualización y orden de eliminación de caché.
- Ensaye cerrar sesión y cambiar de cuenta con trabajo pendiente.
- Pruebe una actualización con datos reemplazables y un borrador antiguo guardado solo en el dispositivo.