FLUTTER EN ACCIÓN. DEL DISEÑO A UNA APP COMPLETA

LUN, 29 / JUN / 2026

Este Informe USERS propone construir una aplicación móvil de seguimiento de hábitos usando una arquitectura híbrida que combina una interfaz en HTML, lógica nativa de Flutter y un widget de Android en la pantalla de inicio. El resultado es una app completa, sin backend, capaz de sincronizar datos entre vistas y recordar al usuario sus compromisos diarios.

Auto: Claudio Bottini

Una arquitectura de tres capas

La propuesta central del Informe es distribuir responsabilidades con claridad. La interfaz principal se escribe en HTML, CSS y JavaScript, cargada dentro de una WebView mediante loadFlutterAsset. Desde ahí, el usuario crea hábitos, marca completados y navega hacia las estadísticas.

Flutter actúa como coordinador. Recibe mensajes JSON a través de un JavaScriptChannel, valida los datos, actualiza el modelo en Dart y persiste el estado con SharedPreferences. También calcula rachas y dispara actualizaciones hacia el widget nativo.

El widget vive en Android puro: un layout XML con RemoteViews y un AppWidgetProvider en Kotlin. Flutter no lo dibuja, le escribe datos y le pide al sistema que lo redibuje.

Aparece una frontera muy clara entre una experiencia web y una app instalada de verdad. Una PWA puede guardar datos, funcionar sin conexión y mostrar notificaciones en ciertos contextos, pero no puede vivir como un widget integrado en el launcher de Android con el mismo nivel de presencia nativa. El widget no es una página web reducida; es un componente del sistema operativo.

El flujo de datos y sus decisiones de diseño

La clave del sistema es mantener una única fuente de verdad en Dart. El widget recibe solo lo necesario para mostrar el estado del día: nombre, icono y si el hábito fue completado. La lógica compleja queda dentro de Flutter.

El historial de cada hábito se guarda como un conjunto de fechas en formato yyyy-MM-dd, no como un booleano. Esto evita el error más frecuente en apps de este tipo: cuando el usuario abre la app al día siguiente, los hábitos aparecen pendientes sin que haga falta reiniciar nada.

El Informe también explica cómo se calcula la racha de forma retroactiva, recorriendo hacia atrás desde hoy y verificando que todos los hábitos activos estuvieran completados en cada fecha.

Diagrama de funcionamiento de nuestra app con su widget nativo. El flujo de datos es fundamental para mantener la información sincronizada en todas las vistas que el usuario puede utilizar.

Detalles de implementación y pruebas

El Informe cubre el código de cada pieza: el HTML de la interfaz, el servicio HabitStore, la clase HomeWidgetService, el provider Kotlin y el NotificationService para recordatorios locales diarios. Para las notificaciones usa flutter_local_notifications con inexactAllowWhileIdle, suficiente para hábitos sin pelear con las políticas de batería.

La pantalla de estadísticas es Flutter puro, sin WebView, porque los gráficos animados con datos locales se resuelven mejor con fl_chart que con una biblioteca JavaScript.

Antes de publicar, el Informe recomienda una prueba de sincronización completa: verificar que marcar un hábito desde la app cambia el widget, y que tocar el widget actualiza la interfaz HTML al volver. Una segunda prueba, cambiando la fecha del emulador al día siguiente, confirma que el historial se conserva y que los hábitos vuelven a aparecer como pendientes para la nueva jornada.

La segunda prueba es temporal: cambiando la fecha del emulador al día siguiente. El widget debe volver a mostrar los hábitos pendientes para el nuevo día, mientras que el historial conserva lo completado el día anterior. Esta prueba detecta el error más común en apps de hábitos: guardar un booleano simple en lugar de guardar completados por fecha.

Encuentra la versión completa de la publicación en la que se basa este resumen, con todos los detalles técnicos en RedUSERS PREMIUM

También te puede interesar:

AHORRA TOKENS OPTIMIZA TUS SESIONES DE DESARROLLO

Este Informe USERS aborda un problema que muchos desarrolladores subestiman: el consumo de tokens en sesiones de trabajo con asistentes de IA. La tesis central es que el desperdicio de contexto no nace de un error puntual, sino de hábitos acumulados que reducen la calidad de las respuestas.


Lee todo lo que quieras, donde vayas, contenidos exclusivos por una mínima cuota mensual. Solo en RedUSERS PREMIUM: SUSCRIBETE!


Comentarios
¡Comparte esta noticia!

Leave a Reply