Componentes de navegación de Android Jetpack: URL del teléfono y la web

El componente de navegación de Android Jetpack cambia por completo y estandariza el método de enrutamiento en Android. Sin embargo, como con toda evolución, existe una curva de aprendizaje para adaptar las convenciones existentes a las nuevas implementaciones. Veamos cómo podemos ajustar esta biblioteca para enrutar a los usuarios a números de teléfono y URL web.

Este artículo es parte de una serie de artículos que se publicarán en las próximas semanas. En esta serie, presentaré los siguientes temas, todos los cuales han sido reempaquetados para aprovechar los componentes de navegación de Android Jetpack:

1. Teléfono y URL (Este artículo)
2. Diálogo reutilizable
3. Regrese a aplicaciones externas en Play Store
4. Información de la aplicación
5. Actividad fructífera
6. Etiqueta personalizada de Chrome
7. Actividad de limpieza de tareas
8. Fragmentos con comportamiento personalizado
9. Enrutamiento de SDK de terceros

Combiné los controladores de URL telefónicos y web en el mismo artículo porque son similares.Sin embargo, primero, me enfocaré exclusivamente en el teléfono y tel: protocolo.

suponer

Quiero que esta extensión acepte y se enrute a cualquier número de teléfono que se le entregue. De esta manera, si mi aplicación puede enrutarse a varios números de teléfono, solo necesito un nodo en el gráfico de navegación para manejar todos estos números de teléfono.

En términos de código, quiero que el mapa de navegación se vea así:

La ruta a este destino debería verse así:

Es razonable esperar un cierto grado de tolerancia a fallos. Específicamente, hacer una llamada desde un dispositivo sin un marcador telefónico (como una tableta) no debería fallar silenciosamente y ciertamente no debería hacer que la aplicación se bloquee. En este caso, quiero mostrar el número al usuario para que pueda realizar llamadas desde el teléfono fijo.

Ahora que se han establecido las expectativas, podemos comenzar a implementar.

Construye el esqueleto

Cada navegador personalizado tiene un marco básico, y debemos implementarlo antes de profundizar en él. La base de nuestro navegador se ve así:

Permítame desglosar las partes relevantes:

• @Navigator.Name("telephone") -El nombre del nodo que aparecerá en el archivo XML del mapa de navegación.En este caso, usaría <telephone /> Crea un destino así.
• Navigator<> -Todos los navegadores personalizados deben heredar de esta clase.
• popBackStack() = true -Dado que es probable que el marcador sea una aplicación externa, sus gráficos no son responsables de la pila de retorno externa.Entonces, cada vez que el marcador finaliza y regresa a su aplicación, este destino ha aparecido y el navegador indica true La eliminación fue exitosa.
• @NavDestination.ClassType(Activity::class) -No es estrictamente obligatorio, pero me gusta que el mapa de navegación sepa qué tipo de vista será el destino.Dado que la aplicación de marcador de Android es casi con seguridad una aplicación externa de su aplicación, creo que es una aplicación universal Activity Algún tipo.
• class Destination -No es muy emocionante en esta situación. Esta clase generalmente asigna y obtiene atributos personalizados que se pasan de XML al código Kotlin (o Java) para su procesamiento posterior. Sin embargo, dado que elegí pasar mis atributos dinámicamente a través de parámetros, no necesito especificar ningún atributo de parámetro estático aquí.

Implementación directa

Para la primera iteración de nuestro trabajo, ignoremos los casos extremos y supongamos que cuando se proporciona un número de teléfono, el sistema operativo siempre puede usar un controlador para realizar una llamada.Como era de esperar, hemos completado el trabajo necesario. createDestination() y popBackStack() método.El resto es navigate() método.

Si recuerda mi ejemplo XML anterior, espero que haya uno <argument /> Tener un nombre phoneNumber Para proporcionar datos, necesito manejar el enrutamiento correctamente.Esta información proviene de args Parámetros en navigate() Función. La información obtenida es la siguiente:

precaución return null Al final del método.La razón de esto es la misma que popBackStack() = true. Si vuelvo destinationEsto agregará este navegador a la pila de retorno de la aplicación actual y lo enrutará al marcador externo.En este caso, dejo el estado de mi back stack solo devolviendo nullNo tener que administrar otra pila de backend facilita mi trabajo.

Manejo de errores

Vi tres problemas obvios en la implementación anterior:

1. ¿Qué pasa si el número de teléfono proporcionado es nulo o está en blanco?
2. ¿Qué pasa si el número no es válido?
3. Qué hacer si el dispositivo no tiene un programa de procesamiento tel: Protocolo (es decir, sin aplicación de marcador)?

El primer problema y el último problema son fáciles de resolver.

El segundo problema es una pendiente bastante resbaladiza. Por esta razón, varias bibliotecas de Android se han elevado a la cima. Son PhoneNumberUtils y libphonenumber. Sin embargo, según mi investigación, cada biblioteca tiene una gran cantidad de trampas, y estas trampas parecen no tener un razonamiento razonable o esperan números en formatos ligeramente diferentes, incluso si todavía funcionan. Mi sugerencia es abandonar este tipo de verificación en el navegador. En todas las aplicaciones que desarrollo, los números de teléfono proporcionados están predeterminados, ya sea codificados o provienen de una base de datos mantenida por nuestra empresa. De hecho, si distribuimos números de teléfono con formato incorrecto, el problema con el que tenemos que lidiar es mucho mayor que dejarlos pasar por nuestro navegador telefónico.

uso

Antes de que comencemos a utilizar nuestro nuevo navegador, el host de navegación debe conocer su existencia. Esto se hace agregando nuestro navegador a la lista de navegadores compatibles existentes.

Primero, cree un nuevo host de navegación llamado CustomNavHostFragment E implementarlo así:

Finalmente, abra el archivo de diseño de la actividad que contiene el host de navegación y reemplace android:name Un atributo con un nombre de clase totalmente calificado para el host de navegación que acaba de crear:

Ahora puede enrutar libremente a su nuevo tipo de destino, como se describe al principio de este artículo.Agreguemos este nuevo destino a nuestro nav_graph.xml documento:

Desde aquí, podemos encaminar a nuestro antojo:

Para aquellos con experiencia en la web, no es sorprendente saber que la única diferencia entre un controlador HTTP y un controlador de teléfono es el protocolo.Uso del enlace de red http: Cualquiera https:, Mientras el teléfono usa tel:Esta sección presentará las diferencias en la realización y las expectativas de este tipo de destino de navegación.