Proyecto completo

Once lecciones han aislado, cada una, una dificultad. Es necesario para aprender, pero insuficiente para saber construir: en una aplicación real, estas piezas interactúan, y es esa interacción la que plantea las preguntas difíciles. ¿Dónde colocar el código que decide leer la caché en lugar de la red? ¿Cómo avisa un formulario a la lista de que un elemento ha cambiado? ¿Qué ve el usuario mientras una escritura local espera una confirmación remota?

Vamos a construir Carnet, un gestor de tareas sincronizado. La elección no es casual: es el dominio más pequeño que exige a la vez una base de datos local, una API, un estado compartido entre pantallas, un formulario validado y funcionamiento sin conexión. Una aplicación de demostración más vistosa pero puramente local no enseñaría nada más que la lección 4.

El énfasis está en la arquitectura, es decir, en las fronteras entre las capas. Un código Flutter se vuelve inmanejable casi siempre por la misma razón: la lógica de negocio acaba en los build, las llamadas de red en los onPressed y el SQL en los widgets. Separar cuesta algunos archivos más al principio y permite probar, modificar y comprender después.