Estado y flujo de datos

Es aquí donde CrossFly más sorprende a quien viene de Flutter, Compose, SwiftUI o React. Dos ausencias deliberadas:

• No hay binding reactivo automático. Nada de setState, observables, @State ni recomposición. Cambiar el modelo no actualiza la UI por sí solo.
• No hay contenedor de inyección de dependencias. Nada de Dagger/Guice/Spring. Tú construyes y pasas tus dependencias a mano (típicamente por el constructor de la pantalla).

El modelo: imperativo + invalidación explícita

Tú lees/escribes el modelo, actualizas el componente directamente y el framework repinta:

model.nome = "Ana";
label.setText(model.nome);   // la mayoría de los setters ya invalida el layout y llama a repaint()

La mayor parte de los setters de componente ya dispara repaint()/invalida el layout por ti. La regla única a recordar:

¿Cambiaste estado que el framework no conoce (un contador tuyo, un cálculo, un campo dibujado en el onPaint)? Tú llamas a repaint(). (Ver La paint thread.)

El contraejemplo clásico

this.progresso = 0.7f;   // cambié un campo que solo mi onPaint lee…
// …y la pantalla no cambia. Falta:
Component.repaint();      // ✔ ahora el próximo frame refleja el nuevo valor

“Cambié el estado y la pantalla no se actualizó” es, casi siempre, un repaint() faltante.

Por qué esta elección

• Previsibilidad: el flujo es lineal y visible — dato → setter → repaint → frame. No hay recomposición mágica ni ciclo reactivo escondido que depurar.
• Cero magia, bajo costo: sin grafo de dependencias reactivo, sin framework de DI que configurar.
• El precio es la explicitud: gestionar el estado es responsabilidad de la aplicación, no del framework.

Los mecanismos de comunicación que ofrece el framework

• Callbacks / actions — onAction(...), callbacks pasados por constructor (ver Devolver valores).
• Jerarquía padre/hijo — navegar el árbol de componentes.
• property(k, v) — el “saco de datos” por componente (ver Todo es un Component).
• Estado global — campos estáticos/servicios compartidos cuando tenga sentido.

El patrón recomendado

Como el framework solo da los bloques, el patrón de organización (un ViewModel/controller por pantalla + repositorio para los datos) es convención de la aplicación — documentado en best-practices. El framework no impone arquitectura; ofrece componentes y el par setter→repaint().

Ver también

• Relacionado: La paint thread · Arquitectura de app (best-practices)