Canales: la unidad de control que cedes al usuario

Durante los primeros ocho años de Android, la aplicación era soberana sobre su propia molestia. Decidía el sonido, la vibración, la prioridad y la insistencia de cada aviso, y el usuario solo tenía dos opciones frente a una app abusiva: aguantarla o silenciarla por completo. Ese equilibrio produjo exactamente lo que la teoría de juegos predice cuando el coste de interrumpir lo paga alguien que no decide: una carrera hacia el ruido en la que ninguna aplicación podía permitirse ser discreta porque las demás no lo eran. Android 8 rompió la carrera por decreto arquitectónico. A partir de ahí, toda notificación pertenece obligatoriamente a un canal, y todo canal es un panel de control que el usuario puede ajustar sin tu permiso y contra tu voluntad. Entender los canales no es aprender una API de tres líneas: es aceptar que estás diseñando la interfaz de negociación entre tu producto y la paciencia de quien lo usa.

El desplazamiento del poder y su lógica

Antes de los canales, la prioridad de una notificación era un campo que tú rellenabas. La consecuencia práctica es fácil de reconstruir: si tu competidor marcaba sus avisos como máxima prioridad y aparecía flotando sobre la pantalla, tú tenías un incentivo directo para hacer lo mismo, y el usuario acababa con un sistema donde todo era urgente y, por tanto, nada lo era. El diseño ponía la decisión de interrumpir en manos de quien se beneficiaba de interrumpir y no soportaba el coste.

El canal invierte esa asimetría con un mecanismo simple. Tú declaras una categoría de contenido y una importancia deseada; el sistema traduce esa declaración en unos ajustes iniciales; y a partir del primer instante esos ajustes pertenecen al usuario. Puede bajarle el sonido a tu canal de promociones, dejar el de mensajes directos flotando sobre todo, y desactivar por completo el de recordatorios. Tu código sigue emitiendo exactamente igual, sin saberlo y sin poder impedirlo.

La consecuencia de diseño es que un canal ya no es un detalle de implementación sino una unidad de producto. El nombre que le pongas aparecerá literalmente en los ajustes del sistema, junto a un interruptor, delante de una persona que no tiene ningún contexto sobre tu código. Un canal llamado servicio de sincronización de trabajos diferidos es un fracaso de comunicación antes que un fracaso técnico: el usuario que no entiende qué apaga tiende a apagarlo todo.

Diseñar la taxonomía antes de escribir código

La pregunta que debe guiar el diseño no es qué tipos de notificación emite mi sistema, sino qué decisiones distintas querría tomar un usuario razonable. Son cosas diferentes y confundirlas produce las dos patologías habituales.

La primera es el canal único, heredado de la migración perezosa: una aplicación entera con un solo canal llamado general. El usuario que recibe una promoción molesta a las once de la noche solo tiene un interruptor, y al usarlo también apaga el mensaje de que su pedido ha salido. Has convertido una queja recuperable en una desactivación total.

La segunda es la explosión de canales, que aparece cuando alguien mapea mecánicamente cada tipo de evento del backend a un canal. Treinta canales en la pantalla de ajustes no son treinta grados de control: son una lista que nadie lee y en la que la única acción viable sigue siendo apagarlo todo desde arriba. El número razonable para la mayoría de aplicaciones está entre tres y siete, y cada uno debe corresponder a una intención humana identificable.

private fun crearCanales(contexto: Context) {
    val gestor = contexto.getSystemService(NotificationManager::class.java)

    val mensajes = NotificationChannel(
        "mensajes_directos",
        contexto.getString(R.string.canal_mensajes),
        NotificationManager.IMPORTANCE_HIGH,
    ).apply {
        description = contexto.getString(R.string.canal_mensajes_desc)
        enableVibration(true)
        setShowBadge(true)
    }

    val pedidos = NotificationChannel(
        "estado_pedido",
        contexto.getString(R.string.canal_pedidos),
        NotificationManager.IMPORTANCE_DEFAULT,
    )

    val promociones = NotificationChannel(
        "promociones",
        contexto.getString(R.string.canal_promociones),
        NotificationManager.IMPORTANCE_LOW,
    )

    gestor.createNotificationChannels(listOf(mensajes, pedidos, promociones))
}

Cuando el número de canales crece de forma legítima —porque hay muchas conversaciones, muchos proyectos o muchos dispositivos vinculados— existe la agrupación mediante NotificationChannelGroup. Un grupo es una cabecera visual en los ajustes que reúne canales relacionados y ofrece un interruptor colectivo. La regla útil es que los grupos representan entidades del dominio del usuario, no categorías técnicas: un grupo por cuenta cuando la app admite varias sesiones, o un grupo por espacio de trabajo, funcionan; un grupo llamado avisos del sistema no aporta nada.

Importancia declarada frente a comportamiento real

La importancia no es una etiqueta decorativa: determina literalmente qué hace el sistema con tu notificación. Conviene memorizar los cinco escalones por su efecto observable y no por su nombre.

En importancia máxima la notificación irrumpe sobre la pantalla actual con sonido. En importancia alta suena y aparece en la barra de estado. En importancia por defecto suena pero no interrumpe visualmente. En importancia baja aparece sin sonido. En importancia mínima se contrae al cajón sin icono en la barra. Ese último escalón es el correcto para casi todo lo que hoy se emite con más ruido del que merece.

Aquí aparece el concepto que más confusión genera y que conviene fijar con precisión: la importancia efectiva. Lo que el usuario percibe no es la importancia que declaraste sino el resultado de combinar tu declaración con la elección del usuario, con el estado de no molestar, con el modo de concentración activo y con los ajustes globales de la aplicación. Tu declaración es únicamente el valor inicial de una negociación que puede terminar en cualquier punto por debajo, y nunca por encima.

flowchart TD
A[La app declara importancia inicial] --> B[El sistema crea el canal]
B --> C{El usuario ajusta el canal}
C -->|sube o baja| D[Importancia del canal segun el usuario]
C -->|no toca nada| D
D --> E{Estado global y modo de concentracion}
E -->|permite| F[Importancia efectiva aplicada]
E -->|silencia| G[Notificacion visible pero muda]
E -->|bloquea| H[Nada llega al usuario]
style H fill:#f38ba8,color:#11111b
style F fill:#a6e3a1,color:#11111b

Como la importancia efectiva es observable, emitir a ciegas es un error evitable. Antes de construir una notificación cara —descargar una imagen, resolver datos de red— conviene comprobar si su canal existe, si sigue activo y si el usuario no lo ha degradado hasta la irrelevancia. Esta comprobación también alimenta una decisión de producto: si un canal está bloqueado para el noventa por ciento de tu base, el problema no es de entrega sino de contenido.

fun canalUtilizable(contexto: Context, id: String): Boolean {
    val gestor = contexto.getSystemService(NotificationManager::class.java)
    if (!NotificationManagerCompat.from(contexto).areNotificationsEnabled()) return false
    val canal = gestor.getNotificationChannel(id) ?: return false
    return canal.importance != NotificationManager.IMPORTANCE_NONE
}

La inmutabilidad y sus consecuencias irreversibles

El punto que más caro se paga es también el menos evidente al leer la API: llamar a la creación de un canal que ya existe no lanza ninguna excepción, no devuelve ningún error y no modifica sus ajustes. Solo el nombre y la descripción se actualizan. Si publicaste un canal con importancia máxima y meses después decides bajarlo, ese cambio no llegará a ninguno de los usuarios que ya lo tienen. Tu código dirá una cosa y el dispositivo hará otra, indefinidamente.

La razón del diseño es defendible: si una actualización pudiera reescribir los ajustes, cualquier aplicación recuperaría el sonido que el usuario le quitó con solo publicar una versión nueva, y todo el mecanismo de control quedaría vacío. La inmutabilidad es lo que hace que la decisión del usuario sea creíble.

La consecuencia operativa es que un canal mal diseñado es deuda permanente. Solo existe una salida, y es destructiva: borrar el canal y crear otro con un identificador distinto. El borrado descarta las preferencias asociadas, de modo que un usuario que había subido el volumen o elegido un tono concreto vuelve al punto de partida sin haberlo pedido. Además, los canales borrados siguen siendo visibles para el usuario en algunos ajustes del sistema durante un tiempo, precisamente para que el reciclaje de identificadores no sea una vía de escape silenciosa.

// Migracion consciente: solo cuando el canal antiguo es indefendible
private fun migrarCanalRuidoso(gestor: NotificationManager) {
    val antiguo = gestor.getNotificationChannel("general")
    if (antiguo != null && antiguo.importance == NotificationManager.IMPORTANCE_HIGH) {
        gestor.deleteNotificationChannel("general")
        gestor.createNotificationChannel(
            NotificationChannel(
                "general_v2",
                "Avisos de la aplicacion",
                NotificationManager.IMPORTANCE_DEFAULT,
            )
        )
    }
}

De ahí se deriva la única disciplina que evita el problema: la taxonomía de canales se diseña antes del primer lanzamiento, se revisa con la misma seriedad que un esquema de base de datos y se documenta con sus identificadores estables. Crear canales bajo demanda, cuando llega el primer mensaje de cada tipo, es una comodidad que además produce un efecto secundario indeseable: la pantalla de ajustes aparece vacía o incompleta hasta que el usuario haya recibido de todo, lo que le impide configurar preventivamente lo que quiere y no quiere.

Queda un matiz relevante para aplicaciones profesionales gestionadas. Los perfiles de trabajo y las políticas de dispositivo pueden imponer restricciones adicionales sobre los canales, y en ciertos casos bloquear categorías enteras al margen de lo que el usuario o la aplicación pidan. No es una excepción exótica: es un recordatorio de que el canal es una petición dentro de una jerarquía de autoridades, y tu código está en el escalón más bajo de todos.