Deep links: de una URL a una pantalla concreta

Hasta ahora los intents circulaban entre aplicaciones que estaban en el mismo dispositivo y que hablaban un vocabulario común. Un deep link rompe esa frontera: convierte una cadena de texto —un enlace en un correo, un botón de una página web, un mensaje de notificación, un código impreso en un cartel— en una entrada directa al interior de tu aplicación, saltándose la pantalla principal y todo el camino que normalmente lleva hasta allí. Ese salto es la razón de su enorme valor comercial y también la fuente de todos sus problemas, porque una pantalla a la que se llega desde fuera no puede dar por supuesto nada de lo que las pantallas interiores dan por supuesto: ni que el usuario esté autenticado, ni que haya datos cargados en memoria, ni que exista una pila de retroceso detrás, ni siquiera que el identificador que viene en la dirección corresponda a algo que siga existiendo.

Esquema propio frente a enlace HTTP

La forma más antigua de deep link inventa un esquema, algo como miapp seguido de dos puntos, y declara un filtro que lo atienda. Funciona en un solo paso, no requiere servidor ni verificación, y es la vía natural para comunicaciones internas y para flujos de retorno de sistemas de autenticación. Su defecto es estructural y no tiene arreglo: si la aplicación no está instalada, la dirección no significa nada para nadie. El navegador muestra un error, el cliente de correo no la convierte en enlace y el usuario se queda mirando una cadena rota.

El enlace HTTP resuelve exactamente eso. Como la dirección es una dirección web real, siempre hay un destino: con la aplicación instalada abre la pantalla, y sin ella abre la página equivalente en el navegador. Esa continuidad es la razón por la que todo enlace que vaya a salir de tu control —correos, redes sociales, mensajes, publicidad— debe ser HTTP, y por la que los esquemas propios deberían quedar reservados a lo que nunca abandona el dispositivo.

<activity
    android:name=".MainActivity"
    android:exported="true"
    android:launchMode="singleTop">

    <!-- esquema propio: rapido, interno, inutil sin la app instalada -->
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="miapp" android:host="articulo" />
    </intent-filter>

    <!-- enlace http: siempre resuelve, con app o sin ella -->
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="https" android:host="ejemplo.com"
              android:pathPrefix="/articulo" />
    </intent-filter>
</activity>

La categoría BROWSABLE es imprescindible y a la vez es la señal de alarma más útil del manifiesto. Significa literalmente que el intent puede haber sido originado por contenido que tú no escribiste, y por tanto que la pantalla receptora está expuesta a direcciones fabricadas por cualquiera. Todo lo dicho en la lección anterior sobre validación de entrada se aplica aquí multiplicado, porque el atacante ni siquiera necesita instalar nada: le basta con conseguir que el usuario pulse un enlace.

Navigation Compose: patrones, argumentos y reenvío

Navigation Compose asocia a cada destino una lista de patrones de URI, y cuando llega un intent con una dirección que casa con uno de ellos, el controlador navega a ese destino extrayendo los argumentos del propio patrón. El mecanismo es el mismo que el de las rutas internas, lo que significa que un destino puede ser alcanzable desde dentro y desde fuera sin duplicar nada.

NavHost(navController, startDestination = "inicio") {

    composable(route = "inicio") { Inicio(navController) }

    composable(
        route = "articulo/{id}",
        arguments = listOf(navArgument("id") { type = NavType.StringType }),
        deepLinks = listOf(
            navDeepLink { uriPattern = "miapp://articulo/{id}" },
            navDeepLink { uriPattern = "https://ejemplo.com/articulo/{id}" },
        ),
    ) { entrada ->
        val id = entrada.arguments?.getString("id")
        ArticuloPantalla(id = id)
    }
}

El reenvío del intent cuando la actividad ya estaba viva es la pieza que falta y que ninguna configuración declarativa cubre. El controlador de navegación sabe interpretar un intent, pero solo se le entrega el que había en el momento de crearse la actividad; los que llegan después hay que dárselos a mano.

class MainActivity : ComponentActivity() {

    private var pendiente by mutableStateOf<Intent?>(null)

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            val nav = rememberNavController()
            LaunchedEffect(pendiente) {
                pendiente?.let { nav.handleDeepLink(it); pendiente = null }
            }
            Grafo(nav)
        }
    }

    override fun onNewIntent(intent: Intent) {
        super.onNewIntent(intent)
        pendiente = intent          // la instancia ya existia: hay que reenviarlo
    }
}

flowchart TD
A[Usuario pulsa un enlace] --> B{La actividad ya existe}
B -->|no| C[onCreate con el intent inicial]
B -->|si con singleTop| D[onNewIntent]
C --> E[El NavController interpreta la URI]
D --> F[Reenvio manual a handleDeepLink]
F --> E
E --> G{Casa con algun patron}
G -->|si| H[Navega al destino con argumentos]
G -->|no| I[Cae en el destino inicial]
H --> J{Que hay debajo en la pila}

La pantalla huérfana y la pila sintética

Aquí llega el problema que separa una implementación aceptable de una buena. Cuando el usuario entra por un enlace directo al detalle de un artículo, esa pantalla es la única de la pila. Al pulsar retroceso sale de la aplicación, cosa que resulta desconcertante porque acaba de aterrizar en un sitio del que no ha llegado a ver el contexto. Navigation Compose construye por defecto una pila sintética que va desde el destino inicial del grafo hasta el destino del enlace, lo que en la mayoría de los grafos produce exactamente el comportamiento deseado sin escribir nada.

Cuando el grafo tiene jerarquías anidadas o el camino natural hacia una pantalla no coincide con la cadena de destinos iniciales, hay que tomar el control con NavDeepLinkBuilder, que permite describir explícitamente la pila que debe existir al llegar. Es también la herramienta correcta para los deep links que se emiten desde notificaciones propias, donde la ruta de retorno forma parte de la experiencia y no puede dejarse al azar.

Queda una decisión de producto que suele resolverse mal por omisión. Un enlace hacia una pantalla que exige sesión iniciada puede rechazarse, puede llevar al inicio de sesión y olvidar el destino, o puede llevar al inicio de sesión y continuar hacia el destino al terminar. Solo la tercera respeta la intención del usuario, y exige conservar el destino pendiente durante todo el flujo de autenticación, incluida la posible muerte del proceso mientras el usuario está en otra aplicación recuperando su contraseña.