Por qué ONEDiary guarda primero en tu teléfono

La mayoría de las aplicaciones de diario empiezan con una pantalla de cuenta. ONEDiary empieza con una página vacía. Es una decisión de producto anterior a la ingeniería, pero solo funciona si la capa de almacenamiento está organizada de la misma manera. Por eso fue la primera parte que diseñamos y la que menos hemos cambiado.

La regla: escribir nunca espera a la red

La capa de almacenamiento solo tiene que obedecer una regla. Al tocar guardar, la entrada queda protegida antes de que ocurra cualquier otra cosa. No se queda solo en una cola de subida ni se muestra de forma optimista mientras una petición está en curso: se escribe en el disco del dispositivo, dentro de una transacción que triunfa o falla localmente.

Todo lo demás de este artículo es una consecuencia de esa regla.

Room es la fuente de verdad

ONEDiary guarda las entradas en una base de datos Room del dispositivo. La interfaz nunca lee de la red. Las pantallas observan Room mediante flujos de Kotlin, así que la línea de tiempo, el calendario y la búsqueda muestran las mismas tablas locales y se actualizan en cuanto termina una escritura.

Conviene ser precisos, porque el soporte offline suele construirse al revés: el servidor es la autoridad y el dispositivo conserva una caché que puede invalidarse. Ese diseño funciona para un feed. No es correcto para un diario, donde lo que escribiste no es una caché de nada: es el original y puede que nunca exista otra copia.

• Lecturas siempre vienen de Room. Ninguna pantalla depende de la conectividad para mostrar su estado de carga.
• Escrituras se confirman en Room y después otra capa decide si algo debe salir del dispositivo.
• Conflictos se resuelven contra los datos locales, no impidiendo que escribas.

Firestore es un espejo, no un hogar

Si inicias sesión y activas Sincronización de datos, ONEDiary refleja tus entradas en Firestore para que tus dispositivos con sesión iniciada converjan. Lee la frase en ese orden: iniciar sesión es opcional, la sincronización es otro interruptor y el espejo depende de la base de datos local, no al revés.

En la práctica, la capa de sincronización puede ser lenta, fallar o reintentarlo sin que nada de eso aparezca en la experiencia de escritura. Una subida fallida se reintenta en segundo plano. Nunca es una entrada perdida ni un botón de guardado bloqueado.

Qué hace realmente el modo sin conexión

Es fácil pensar que Modo sin conexión es un interruptor de interfaz que oculta el estado de sincronización. No lo es. Al activarlo, pausa la sincronización con Firestore y mantiene los cambios pendientes en el dispositivo hasta que reanudes.

Existe porque tener conexión y querer usarla son preguntas diferentes, y solo tú puedes responder la segunda. Un plan de roaming caro, escribir algo que todavía no quieres reflejar o simplemente querer apagar la radio son motivos para pausar sin cerrar sesión ni perder la configuración de sincronización.

Al desactivarlo, los cambios pendientes se procesan en segundo plano. Mientras tanto no se descarta nada.

Los valores iniciales explican el diseño

Vale la pena enumerar los tres estados de una instalación nueva, porque el orden es todo el diseño.

1. Instalación nuevaSin cuenta, sin sincronización y sin acceso a la IA. Puedes escribir, leer, buscar, adjuntar fotos y consultar el calendario. La aplicación se entrega así y muchas personas nunca cambian de estado.
2. Sesión iniciada con sincronización activaLas entradas convergen entre los dispositivos donde tienes sesión iniciada. Puedes desactivarla cuando quieras o pausarla con el modo sin conexión.
3. Acceso a la IA permitidoEs un permiso independiente y explícito. Los informes y el chat del diario solo pueden leer tus entradas después de que lo concedas. Activar la sincronización no activa esto.

Nada de esto es una venta adicional escondida bajo el nombre de un ajuste. Todo permanece apagado hasta que tú decides y todo se puede deshacer desde la misma pantalla donde lo activaste.

Lo que nos cuesta

Si somos honestos con el intercambio, local-first da más trabajo, no menos. Mantenemos migraciones para un esquema que vive en dispositivos que no podemos inspeccionar. No podemos reparar una fila defectuosa con un script del servidor. Funciones triviales con una base central, como una búsqueda de texto completo entre dispositivos sobre contenido que nunca recibimos, son más difíciles o quedan fuera de alcance.

Creemos que es el precio correcto para una aplicación cuya tarea es guardar cosas que no puedes recuperar. Pero el precio existe y se paga en cada lanzamiento.