Qué es un widget: tu interfaz ejecutándose en un proceso ajeno

Durante veintisiete niveles todo lo que has dibujado ocurría dentro de tu proceso: tú creabas los objetos, tú los medías, tú los pintabas y tú recibías los eventos que provocaban. Un widget de pantalla de inicio rompe esa unidad de un golpe. La superficie sobre la que aparece pertenece al lanzador, un proceso distinto, escrito por otro equipo, con su propia memoria, su propio hilo principal y su propia idea de cuándo merece la pena redibujar algo. Tu aplicación no dibuja ahí: describe. Fabrica un objeto que enumera qué vistas hay, con qué texto, qué imagen y qué acciones, lo serializa, lo entrega al sistema y se calla. Lo que el usuario ve es esa descripción reconstruida por un desconocido. Toda la incomodidad de esta tecnología, todas sus limitaciones aparentemente arbitrarias y toda la disciplina que exige nacen de esa única frontera entre procesos, y quien la interioriza deja de pelear con la API y empieza a diseñar contra ella.

Cuatro actores y una frontera

El primer actor es tu aplicación, que aporta el proveedor: una clase que hereda de AppWidgetProvider y que, contra toda intuición, no es una vista ni un controlador, sino un BroadcastReceiver. Vive lo que dura la atención de una llamada y muere. El segundo es el sistema, representado por AppWidgetManager, que mantiene el registro de qué widgets existen, a qué identificadores corresponden y quién los aloja. El tercero es el anfitrión, casi siempre el lanzador, que reserva un hueco en su cuadrícula y se compromete a inflar lo que reciba. El cuarto es el usuario, que coloca, redimensiona y toca.

Lo importante es que entre el primero y el tercero no hay memoria compartida, ni referencias, ni retorno de llamada directo. Solo hay mensajes.

sequenceDiagram
participant U as Usuario
participant L as Lanzador anfitrion
participant S as AppWidgetManager
participant A as Tu proceso
U->>L: Coloca el widget en la cuadricula
L->>S: Reserva un identificador
S->>A: Emision de actualizacion al proveedor
A->>A: Construye la descripcion de interfaz
A->>S: Entrega el objeto serializado
S->>L: Reenvia la descripcion
L->>L: Infla las vistas en su jerarquia
L->>U: Pinta el resultado

Merece la pena fijarse en quién falta en ese reparto: no hay ningún objeto que represente al widget dentro de tu aplicación. Lo único que existe por tu parte es un identificador entero que el sistema te entrega y que designa una instancia colocada en algún anfitrión. No puedes preguntarle nada a ese identificador salvo a través del gestor, no puedes conservarlo indefinidamente porque se recicla cuando el usuario retira el widget, y no puedes suponer que corresponde a algo visible, porque el anfitrión pudo haberlo apartado a una página del escritorio que nadie mira desde marzo.

Cada flecha de ese diagrama que cruza de tu proceso hacia fuera es una transacción de Binder, y cada transacción tiene un coste, un límite de tamaño y una latencia. Cuando más adelante te preguntes por qué no puedes pasar un mapa de bits enorme, por qué no puedes actualizar cada segundo o por qué no puedes registrar un escuchador de desplazamiento, la respuesta estará siempre en alguna de esas flechas.

RemoteViews: una interfaz que cabe en un mensaje

RemoteViews no contiene vistas. Contiene la identidad de un recurso de diseño y una lista ordenada de operaciones diferidas del tipo aplica este texto a la vista con este identificador. El anfitrión recibe ese paquete, infla el diseño usando los recursos de tu paquete y ejecuta las operaciones una por una. De ahí se sigue una propiedad que conviene enunciar sin rodeos: el anfitrión ejecuta código de dibujo del sistema sobre recursos tuyos, pero jamás ejecuta código tuyo.

class MiProveedor : AppWidgetProvider() {

    override fun onUpdate(
        context: Context,
        manager: AppWidgetManager,
        ids: IntArray,
    ) {
        val vistas = RemoteViews(context.packageName, R.layout.widget_contador)
        vistas.setTextViewText(R.id.titulo, "Pendientes")
        vistas.setTextViewText(R.id.valor, contarPendientes(context).toString())
        ids.forEach { id -> manager.updateAppWidget(id, vistas) }
    }
}

El registro se hace en el manifiesto y añade un fichero de metadatos que el sistema lee antes incluso de que tu proceso arranque, porque el selector de widgets tiene que mostrar tamaño, previsualización y descripción sin ejecutarte.

<receiver
    android:name=".MiProveedor"
    android:exported="true">
    <intent-filter>
        <action android:name="android.appwidget.action.APPWIDGET_UPDATE" />
    </intent-filter>
    <meta-data
        android:name="android.appwidget.provider"
        android:resource="@xml/mi_widget_info" />
</receiver>

El ciclo de vida de una instancia

El proveedor no recibe una sola llamada sino un repertorio, y cada una marca un momento distinto del ciclo de vida de las instancias que el usuario coloca. Conviene conocerlo entero porque casi todos los errores de recursos huérfanos vienen de ignorar la mitad.

class MiProveedor : AppWidgetProvider() {

    override fun onEnabled(context: Context) { /* primera instancia colocada */ }

    override fun onUpdate(context: Context, m: AppWidgetManager, ids: IntArray) { }

    override fun onAppWidgetOptionsChanged(
        context: Context,
        m: AppWidgetManager,
        id: Int,
        opciones: Bundle,
    ) { /* el usuario redimensiono esta instancia */ }

    override fun onDeleted(context: Context, ids: IntArray) { /* limpia su estado */ }

    override fun onDisabled(context: Context) { /* ya no queda ninguna */ }
}

La distinción entre la primera y la última llamada es la que ordena el trabajo periódico: registrar un trabajador cuando aparece la primera instancia y cancelarlo cuando desaparece la última evita el caso clásico de una aplicación que sigue despertándose cada cuarto de hora meses después de que el usuario retirase el widget del escritorio. La llamada de borrado es igual de importante porque el estado asociado a un identificador que ya no existe se queda para siempre en el disco si nadie lo elimina, y esos identificadores se reciclan.

Hay además un momento anterior a todos: la actividad de configuración. Si el widget necesita que el usuario elija algo antes de mostrar nada, se declara una actividad que el anfitrión lanza en el instante de la colocación y cuyo resultado decide si la instancia se conserva o se descarta. Cancelarla debe dejar el escritorio como estaba, y devolver un resultado correcto es obligatorio para que el widget llegue a aparecer.

El inventario de limitaciones

Todas las restricciones siguientes son consecuencias mecánicas de la frontera. Ninguna es caprichosa y ninguna va a desaparecer.

A esas cuatro conviene añadir una restricción de contexto que no aparece en ninguna lista oficial: no hay ciclo de vida propio y por tanto no hay ningún punto del código que pueda decir ahora el widget es visible. El anfitrión no informa de si su página del escritorio está en pantalla, ni de si el usuario tiene el dispositivo bloqueado, ni de si tu widget quedó tapado por una carpeta abierta. Cualquier diseño que dependa de saber si alguien está mirando es inviable.

Hay una quinta limitación que suele descubrirse tarde y que conviene anticipar: las listas. Una lista con contenido dinámico no cabe en la descripción, porque el anfitrión necesita pedir elementos según desplaza. Para eso existe un servicio propio que actúa de fábrica de filas y al que el anfitrión llama por IPC elemento a elemento; es funcional, es lento y su ciclo de vida es una fuente clásica de datos obsoletos. La generación siguiente de esta tecnología, que estudiarás en la lección próxima, esconde ese mecanismo pero no lo elimina.