Flutter · Firestore · Offline

¿Qué pasa si dos usuarios editan sin conexión?

IndiePack··9 min lectura

Si dos usuarios editan sin conexión el mismo documento de Firestore, define una versión o revisión esperada y evita enviar el documento completo desde Flutter. Al reconectar, acepta campos independientes, rechaza una revisión obsoleta o presenta el conflicto; no supongas que la sincronización conoce la intención de ambos.

Dos problemas distintos: Security Rules deciden quién puede escribir; la política de conflicto decide qué escritura sigue siendo válida.

Índice

  1. ¿Dónde aparece la colisión?
  2. ¿Cuál es la forma rápida?
  3. ¿Qué modelo reduce pérdidas?
  4. ¿Qué ve el usuario?
  5. ¿Cómo se prueba?

¿Por qué una app que sincroniza puede perder un cambio válido?

Puede perderlo cuando ambos dispositivos parten de la misma versión y escriben después valores distintos sobre el mismo campo. La última escritura recibida puede ocultar la anterior aunque las dos estén autorizadas.

Distingue formularios que reemplazan una entidad, contadores, listas y registros históricos. Cada estructura necesita una política diferente; una regla universal de “última escritura gana” rara vez comunica el conflicto. Documenta también qué campos pueden editarse juntos y cuáles exigen revisión humana.

¿Cuál es la forma rápida: usar la base Flutter de IndiePack?

La forma rápida es partir de IndiePack, cuya ruta móvil reúne Flutter, Firebase con Firestore, Cloud Functions, Realtime y reglas de seguridad preconfiguradas. Así añades la regla de concurrencia sobre un backend ya conectado.

Ver IndiePackVer precio

¿Qué estructura evita sobrescribir más datos de los necesarios?

Una estructura con campos pequeños, marcas de versión y operaciones semánticas evita reemplazar todo el documento. Para cambios que deben ser atómicos, una transacción o Cloud Function compara la versión esperada antes de guardar.

La separación entre cliente, reglas y función privilegiada se detalla en el checklist de Firestore, Cloud Functions y Security Rules.

¿Qué debe mostrar Flutter cuando la versión ya ha cambiado?

Debe mostrar que existe una versión nueva, conservar la edición local y ofrecer revisar, reintentar o descartar. Un error genérico de red induce al usuario a repetir la misma escritura sin entender el conflicto.

Si los campos no se solapan, el servidor puede fusionarlos según una regla explícita. Si afectan al mismo valor de negocio, pide una decisión o crea un registro inmutable en lugar de esconder una pérdida.

¿Cómo se prueba una colisión real antes de lanzar?

Se prueba con dos dispositivos que leen la misma revisión, quedan offline, cambian el mismo campo y reconectan en ambos órdenes. Repite con campos distintos, usuario sin permiso y función que falla a mitad.

Verifica que ninguna regla se relaja para “hacer funcionar offline” y que la interfaz conserva el trabajo rechazado. IndiePack sirve como base cuando quieres resolver este detalle de producto sin reconstruir Flutter y Firebase desde cero.