Cambiar a Androidx o una emocionante aventura de rake

El tema de la transición a Androidx está ahora en el aire. Ya hay un breve artículo en inglés de Daniel Lew , hay un informe . Pero todos ellos consideran superficialmente el escenario de transición descrito en la documentación de Google .

Quiero compartir mi experiencia Mi proyecto utiliza Moxy y Cicerone, encuentro mi experiencia interesante, porque en los canales de telegramas oficiales de estas bibliotecas aparece periódicamente la pregunta de cuándo serán transferidos a Androidx.

Simplemente migre a AndroidX ...

Para transferir el proyecto a Androidx, debe seguir algunos pasos simples:

1. Instale compileSdkVersion 28 y targetSdkVersion 28 , actualice todas las bibliotecas de soporte a las últimas versiones.

2. En el archivo gradle.properties agregue las líneas:

android.useAndroidX=true android.enableJetifier=true 

3. Si ya está utilizando Android Studio 3.2, utilice la refactorización:


Él hará la mayor parte (o menos) del trabajo por usted.

Si por alguna razón no está utilizando Git u otro sistema de control de versiones, en esta etapa tendrá la oportunidad de crear un archivo de proyecto:


Haga clic en el botón Migrar, seleccione dónde guardar el archivo y, después de un tiempo, obtendremos el resultado de verificar el proyecto antes de refactorizarlo:


Aquí vemos qué dependencias en build.gradle y en las directivas de importación serán reemplazadas. En el ejemplo de la clase MainActivity, como se puede ver en la captura de pantalla anterior, se reemplazará una dependencia: android.support.v4.view.GravityCompat , pero si abrimos esta clase, veremos que en realidad hay tres dependencias más que deben reemplazarse:


No entendí la razón de este comportamiento selectivo, pero estas dependencias tendrán que repararse manualmente. Haga clic en "Refactorizar".


Entonces, dado que el estudio no pudo reemplazar todas las dependencias (tal vez podría, entonces puede ser felicitado), cuando intente construir un proyecto, verá una lista similar de errores:


Al abrir la clase con errores, veremos algo como esto:


Eliminamos dependencias obsoletas, y mediante la tecla de acceso rápido Alt + Enter importamos clases del paquete androidx


Así arreglamos todas las clases. Si el error no está relacionado con la "importación", no le preste atención, lo más probable es que se deba a los mismos problemas en otra clase.

Por ejemplo:


Los errores aquí están relacionados con el hecho de que en la clase TimelineView también debe eliminar los problemas de importación. Cuando se arreglan todos los errores, volvemos a ejecutar la compilación del proyecto, y quizás volvamos a obtener la lista de errores, solo en otras clases, continuamos el proceso iterativo.

Para los errores con las clases que se generan (Dagger o DataBinding), no preste atención en esta etapa. Si no hay errores en sus clases, y el estudio solo jura por el código generado, entonces necesita ejecutar el Proyecto Limpio y el Proyecto de Reconstrucción.


Si esto no ayuda, puede intentar borrar el caché del estudio:


Tendrá que borrar el caché al menos una vez, para que las clases que generan DataBinding o Room se creen correctamente.

Bibliotecas externas

En general, configuramos el indicador android.enableJetifier = true para que, en la etapa de construcción del proyecto, las dependencias de las bibliotecas externas se reemplacen automáticamente con las correspondientes dependencias de AndroidX, pero por alguna razón esto no sucede.

En cualquier caso, antes de hacer lo que se describe a continuación, asegúrese de que tiene este problema y de que las últimas versiones de las bibliotecas que está utilizando aún no se han traducido a AndroidX.

Moxy

MainActivity en mi proyecto se hereda de MvpAppCompatActivity es la clase Moxy, que, al momento de escribir esto, aún no se ha traducido a AndroidX. Para resolver este problema, copié la clase en mi proyecto, en un paquete Androidx separado, y arreglé las dependencias en él. Es mejor dejar el nombre de la clase sin cambios, por lo que será más fácil actualizar las dependencias.

El mismo procedimiento debe hacerse para fragmentos, para la clase MvpAppCompatFragment .

Tenga en cuenta que hay un genérico en estas clases, en el campo mMvpDelegate , no olvide corregir la dependencia en él, es fácil no notarlo, porque es una dependencia de la clase Moxy y no de la clase de biblioteca de soporte.

Cicerone

Para resolver problemas con Cicerone, tuve que crear una copia de las clases SupportAppScreen y SupportAppNavigator en mi proyecto. Tenga en cuenta que la clase SupportAppNavigator depende de SupportAppScreen. Recuerde corregir esta dependencia en su copia.

Conclusiones

Cambiar a AndroidX es una experiencia emocionante, y tal vez si no tiene una necesidad urgente, debería esperar un poco. Después de todo, cuando la mayor parte del rastrillo se elimine de tu camino, será más fácil y rápido hacerlo. Pero personalmente, estoy contento de que este camino haya pasado, los golpes en la frente sanarán y la experiencia útil permanecerá conmigo.