Muy buenas, me llamo Miguel y hoy les traigo un nuevo post.
Índice
Aproveche lo último que Jetpack tiene para ofrecer
Jetpack es un conjunto de bibliotecas, herramientas y orientación para ayudarlo a escribir aplicaciones de alta calidad con mayor facilidad.
Jetpack facilita la codificación a través de las mejores prácticas, limitando el código estándar y simplificando tareas complejas. Todo con el objetivo de permitirle concentrarse en el código que realmente le interesa.
AndroidX es el nombre del paquete para todas las bibliotecas dentro de Jetpack. Piense en AndroidX como el proyecto de código abierto utilizado para desarrollar, probar, versionar y lanzar bibliotecas Jetpack.
De vuelta en I / O 2018
, Anunciado esa biblioteca de soporte se refactorizaría en el espacio de nombres de AndroidX, que se completó con la biblioteca de soporte 28
y el anuncio de AndroidX 1.0
.
¿Por qué migrar?
Ahora es el momento de migrar del uso de la biblioteca de soporte de Android a AndroidX. Hay cuatro razones detrás de esto:
- La biblioteca de soporte de Android ha llegado al final de su vida útil.
28.0
fue la última versión del espacio de nombres de soporte de Android y el espacio de nombres ya no se mantiene. Por lo tanto, si desea correcciones de errores o nuevas funciones que anteriormente se hubieran incluido en la Biblioteca de soporte, debe migrar a AndroidX. - Mejor gestión de paquetes. Con AndroidX, obtienes versiones estandarizadas e independientes, así como mejores nombres estandarizados y lanzamientos más frecuentes.
- Otras bibliotecas han migrado para usar las bibliotecas de espacio de nombres de AndroidX, incluidos los servicios de Google Play, Firebase, Butterknife, Mockito 2 y SQLDelight, entre otros.
- Todas las nuevas bibliotecas de Jetpack se lanzarán en el espacio de nombres de AndroidX. Entonces, por ejemplo, para aprovechar Jetpack Compose o CameraX, debe migrar al espacio de nombres de AndroidX.
Preparándose para migrar
Antes de comenzar a migrar a AndroidX, debe:
- Respalde su proyecto. Si estás usando herramientas de control de fuente, se recomienda que realice una copia de seguridad, ya que la migración cambiará muchos de los archivos de su proyecto.
- Cree una nueva rama en la que realizar los cambios de migración.
- Si es posible, suspenda o minimice el desarrollo (al menos no intente refactorizar o incorporar nuevas funciones) durante la migración, ya que esto ayudará a reducir la cantidad de conflictos de fusión que podrían ocurrir.
Emigrar
A lo largo de los pasos de migración, céntrese en abordar los errores, hacer que su aplicación se compile y aprobar todas las pruebas.
No se recomienda migrar directamente a AndroidX desde una versión anterior de la biblioteca de soporte, digamos 26
o 27
: no solo necesitaría abordar los cambios en el espacio de nombres, también necesitaría abordar los cambios de API entre la versión anterior y AndroidX.
Por lo tanto, se recomienda que actualice a la versión 28
, aborde todos los cambios de API y se asegure de que su aplicación se compile con la versión 28
.
Support Library versión 28
y AndroidX 1.0 son equivalentes binarios, lo que significa que solo cambia el nombre del paquete entre esas dos versiones: todas las API son iguales.
Esto significa que debería tener muy poco que arreglar al migrar de 28
a AndroidX.
Jetifier ayuda a migrar dependencias de terceros para usar AndroidX. Jetifier cambiará el código de bytes de esas dependencias para hacerlas compatibles con proyectos que usan AndroidX.
Sin embargo, Jetifier no cambiará su código fuente ni migrará su código generado.
Para habilitar Jetifier en su aplicación, agregue lo siguiente a su archivo gradle.properties
:
android.useAndroidX=true android.enableJetifier=true
Ahora, cuando el código de autocompletado importe bibliotecas, importará la versión de AndroidX de esa biblioteca en lugar de la versión anterior de la biblioteca de soporte.
Antes de comenzar la migración, debe actualizar cada biblioteca de terceros, como Butterknife, Glide, Mockito 2 y SqlDelight, a la versión más reciente de la biblioteca. No hacerlo podría provocar errores de compilación inexplicables.
Si está utilizando una biblioteca de generación de código, Jetifier no los modificará. Por lo tanto, deberá verificar que la biblioteca de generación de código sea compatible con AndroidX.
Si considera omitir los pasos 2
y 3
, estos son algunos de los errores que podría encontrar:
- El código de terceros que está utilizando no es compatible con AndroidX. En este caso, un seguimiento de pila similar al siguiente le mostrará que está tratando de extraer la versión anterior de la biblioteca de soporte:
… Error : Program type already present: android.support.v4.app.INotificationSideChannel$Stub$Proxy | Reason: Program type already present: android.support.v4.app.INotificationSideChannel$Stub$Proxy …
- Si tiene un proyecto que se ha migrado parcialmente, es posible que obtenga un error de clase duplicada, donde está intentando extraer el mismo código tanto de la biblioteca de soporte como de AndroidX. El seguimiento de la pila le mostrará algo como esto:
… Duplicate class android.support.v4.app.INotificationSideChannel found in modules classes.jar (androidx.core:core:1.0.0) and classes.jar (com.android.support:support-compat:28.0.0) …
Tienes 3
opciones para actualizar tu código fuente para usar AndroidX:
- Estudio de Android.
- Actualización manual.
- Guión bash.
Si usa Android Studio 3.2 estable o superior, puede actualizar su código fuente usando el Migrar a AndroidX opción en el Refactor menú.
Esta es la forma recomendada, ya que Android Studio puede examinar su código fuente para tomar decisiones correctas al refactorizar.
Si no usa Android Studio o emplea una arquitectura de aplicación más sofisticada que la opción Migrar a AndroidX no cubre, debería aprovechar la archivo csv de mapeo de clases para implementar un script de búsqueda y reemplazo de bash.
Este script debe encontrar todas las instancias de código fuente de las clases android.support
y luego reemplazarlas con su equivalente de AndroidX.
Sin embargo, debido a que este es un enfoque de fuerza bruta para la migración, es posible que esta búsqueda y reemplazo básicos no completen la migración de manera suficiente o correcta.
Además, la actualización también se puede realizar manualmente.
Si decide adoptar el enfoque manual, visite la página Migrar a AndroidX, donde puede encontrar una mapeo de artefactos que detalla los paquetes de la biblioteca de soporte y su asignación de clases correspondiente es AndroidX. También puede descargar el archivo CSV desde esta página.
Y eso es todo, ahora debería tener un proyecto que compile y use AndroidX.
Esas molestas excepciones
Si bien las herramientas y los procesos que hemos discutido aquí deberían guiar a la mayoría de las aplicaciones a través de la migración sin problemas, hemos descubierto que hay algunos casos en los que es posible que deba realizar cambios manualmente.
Archivos de configuración de versión
Deberá volver a aplicar manualmente las variables que definen las versiones de la biblioteca. Para ilustrar, su build.gradle
El archivo podría verse así antes de la migración:
ext.versions = [ ‘drawer’ : ‘28.0.0’, ‘rview’ : ‘28.0.0’ ] implementation “com.android.support:drawerlayout:$ {versions.drawer}” implementation “com.android.support:recyclerview-v7:$ {versions.rview}”
Luego, después de ejecutar la herramienta de migración, terminas con esto:
ext.versions = [ ‘drawer’ : ‘28.0.0’, ‘rview’ : ‘28.0.0’ ] implementation “androidx.drawerlayout:drawerlayout:1.0.0” implementation “androidx.recyclerview:recyclerview:1.0.0”
DrawerLayout
y RecyclerView
están usando los paquetes de AndroidX, pero los números de versión ahora están en línea.
Además, los números de variable de las versiones no se han modificado. Por lo tanto, deberá realizar una actualización manual de esto:
ext.versions = [ ‘drawer’ : ‘1.0.0’, ‘rview’ : ‘1.0.0’ ] implementation “androidx.drawerlayout:drawerlayout:$ {versions.drawer}” implementation “androidx.recyclerview:recyclerview:$ {versions.rview}”
ProGuard y compilar scripts
La herramienta de migración no automatiza las actualizaciones de ProGuard
ni de ningún script integrado asociado. Por lo tanto, si los está utilizando y tiene nombres de paquetes en ellos, deberá editarlos manualmente.
Obtenga la última versión estable
La herramienta de migración incluye la versión más reciente de las bibliotecas de AndroidX. Como resultado, puede terminar con una versión alfa de algunas bibliotecas en lugar de la versión estable.
Por ejemplo, la versión de la biblioteca de soporte antes de la migración podría ser:
implementation ‘com.android.support:appcompat-v7:28.0.0’
Y después de la migración, estaría usando la versión alfa de la correspondiente biblioteca de AndroidX:
implementation ‘androidx.appcompat:appcompat:1.1.0-alpha01’
Entonces, si prefiere usar la versión estable de la biblioteca, deberá actualizar manualmente la versión:
implementation ‘androidx.appcompat:appcompat:1.0.2’
Más ayuda y recursos
Puede encontrar más información sobre este proceso, las herramientas y los problemas que puede encontrar en developer.android.com Migrar a AndroidX página.
La página incluye una descripción general del proyecto de AndroidX, una guía de migración y la tabla de mapeo de la biblioteca de soporte anterior a las nuevas versiones de AndroidX estable y alfa con los archivos CSV que necesita para realizar la migración.
En otra parte, también hay un artículo que detalla la migración a AndroidX en el proyecto de ejemplo de Plaid.
Y finalmente, hay un rastreador de problemas donde ve los problemas de la herramienta de migración en los que está trabajando el equipo.
Por supuesto, puede informar cualquier problema que encuentre con la herramienta de migración aquí usando el botón en la parte superior izquierda de la página.
Si no se ha actualizado a AndroidX, este es un buen momento para hacerlo y aprovechar el desarrollo optimizado que las bibliotecas Jetpack ofrecen a sus aplicaciones.
Si sigue las instrucciones de este artículo, descubrirá que, en la mayoría de los casos, la migración es algo sencillo y fácil de hacer.
Gracias por leer este post.
Añadir comentario