Estado y actualización: quién decide cuándo cambia el widget

En una pantalla ordinaria nunca te has preguntado cuándo se actualiza la interfaz, porque la pregunta no tiene sentido: hay un bucle de fotogramas, hay un compositor observando estados y la respuesta es siempre en cuanto haga falta y como muy tarde dentro de dieciséis milisegundos. Un widget no tiene bucle de fotogramas. Lo que muestra es una fotografía que alguien envió en algún momento del pasado, y seguirá mostrándola hasta el fin de los tiempos si nadie envía otra. Puede llevar horas siendo falsa. Puede sobrevivir a un reinicio del dispositivo mostrando el saldo de ayer. Y ni el sistema, ni el anfitrión, ni el usuario van a corregirlo por ti, porque ninguno de los tres sabe que ha dejado de ser cierta. La actualización de un widget no es una optimización ni un detalle de rendimiento: es una responsabilidad arquitectónica completa que tienes que diseñar, y que se resuelve con dos preguntas encadenadas, dónde vive lo que el widget muestra y quién avisa de que ha cambiado.

El estado del widget y la fuente de verdad

Glance asocia a cada instancia colocada un almacén persistente, respaldado por defecto por un fichero de preferencias y accesible desde la composición mediante currentState. La palabra clave es instancia: si el usuario coloca tres copias del mismo widget configuradas para tres ciudades distintas, hay tres almacenes independientes identificados por su GlanceId. Ese estado sobrevive al reinicio del dispositivo y a la muerte del proceso, y es el único sitio donde algo puede sobrevivir entre composiciones.

object Claves {
    val ciudad = stringPreferencesKey("ciudad")
    val grados = intPreferencesKey("grados")
}

class TiempoWidget : GlanceAppWidget() {
    override val stateDefinition = PreferencesGlanceStateDefinition

    override suspend fun provideGlance(context: Context, id: GlanceId) {
        provideContent {
            val prefs = currentState<Preferences>()
            val ciudad = prefs[Claves.ciudad] ?: "Sin configurar"
            Text(text = ciudad + " " + (prefs[Claves.grados] ?: 0) + " grados")
        }
    }
}

La escritura se hace desde fuera de la composición y termina siempre pidiendo una nueva traducción, porque cambiar el almacén sin avisar no repinta nada.

suspend fun refrescar(context: Context, id: GlanceId, grados: Int) {
    updateAppWidgetState(context, id) { prefs ->
        prefs[Claves.grados] = grados
    }
    TiempoWidget().update(context, id)
}

Configuración por instancia y limpieza

Si dos instancias del mismo widget pueden mostrar cosas distintas, alguien tiene que decidir cuál muestra qué, y ese alguien es una actividad de configuración que el anfitrión lanza en el momento de la colocación. Su trabajo consiste en escribir el estado inicial de esa instancia concreta y pedir el primer repintado antes de devolver el resultado.

class ConfigActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val widgetId = intent.getIntExtra(
            AppWidgetManager.EXTRA_APPWIDGET_ID,
            AppWidgetManager.INVALID_APPWIDGET_ID,
        )
        setResult(RESULT_CANCELED)
        setContent {
            SelectorDeCiudad { ciudad ->
                lifecycleScope.launch {
                    val id = GlanceAppWidgetManager(this@ConfigActivity)
                        .getGlanceIdBy(widgetId)
                    updateAppWidgetState(this@ConfigActivity, id) {
                        it[Claves.ciudad] = ciudad
                    }
                    TiempoWidget().update(this@ConfigActivity, id)
                    setResult(RESULT_OK, Intent().putExtra(
                        AppWidgetManager.EXTRA_APPWIDGET_ID, widgetId))
                    finish()
                }
            }
        }
    }
}

Fijar el resultado cancelado desde el principio es lo que hace que abandonar la configuración deje el escritorio como estaba. Y hay una obligación simétrica al final de la vida: cuando el usuario retira una instancia, Glance ofrece un punto donde borrar su estado y cancelar cualquier trabajo periódico registrado en su nombre. Omitirla produce ficheros de preferencias huérfanos y, mucho peor, trabajos que siguen despertando la aplicación para actualizar widgets que ya no existen.

Quién dispara la actualización

Hay cuatro orígenes legítimos y conviene tener presente cuál corresponde a cada caso.

flowchart TD
A[Cambia el dominio] --> E[updateAll o update por id]
B[Trabajador periodico de WorkManager] --> E
C[Emision del sistema o push recibido] --> E
D[Interaccion del usuario en el widget] --> E
E --> F[Se escribe el estado del widget]
F --> G[Nueva composicion y traduccion]
G --> H[Transaccion hacia el anfitrion]
H --> I[El lanzador repinta]

El primero y mejor es el dominio: cuando tu repositorio escribe algo que el widget muestra, esa misma operación pide el repintado. Es inmediato, es exacto y no gasta nada cuando no hay cambios. El segundo es el trabajo periódico, adecuado solo cuando el dato depende del tiempo o de un servidor que no puede avisar. El tercero son las señales del sistema y los mensajes push, ideales para datos que cambian por decisión ajena. El cuarto lo verás en la lección siguiente.

class RefrescoWorker(ctx: Context, params: WorkerParameters) :
    CoroutineWorker(ctx, params) {

    override suspend fun doWork(): Result {
        val datos = repositorio.sincronizar()
        val manager = GlanceAppWidgetManager(applicationContext)
        manager.getGlanceIds(TiempoWidget::class.java).forEach { id ->
            updateAppWidgetState(applicationContext, id) { it[Claves.grados] = datos.grados }
        }
        TiempoWidget().updateAll(applicationContext)
        return Result.success()
    }
}

El periodo mínimo de un trabajo periódico es de quince minutos y no es negociable; el ancho de la ventana de flexibilidad y el agrupamiento que hace el sistema pueden convertirlo en bastante más. Añadir la restricción de red conectada evita despertares inútiles, y encadenar el registro con la política de mantener el existente evita multiplicar trabajos cada vez que arranca la aplicación.

Lo que cuesta refrescar

Conviene enumerar el coste real de un refresco, porque casi siempre se subestima y porque el usuario lo paga en una moneda que sí percibe. Despertar tu proceso si no estaba vivo implica cargar el entorno de ejecución, inicializar la inyección de dependencias y abrir la base de datos. Componer y traducir consume CPU. Serializar y cruzar Binder consume memoria del búfer compartido. Y el anfitrión, al recibir la descripción, infla vistas y repinta una porción de su jerarquía, gasto que el sistema atribuye a él pero que provocaste tú.

Hay además una asimetría que conviene explotar: cuando el widget es visible y su sesión de composición sigue viva, observar un flujo dentro de la composición produce repintados sin coste de despertar. Cuando no lo es, cualquier intento de mantener observación continua es tiempo de CPU gastado para nada. La estrategia correcta combina las dos: reactividad fina mientras el sistema te la regala, invalidación explícita y espaciada cuando no.