Passer à Androidx ou une aventure de râteau passionnante

Le thème de la transition vers Androidx est désormais dans l'air. Il y a déjà un court article en anglais de Daniel Lew , il y a un rapport . Mais tous considèrent plutôt superficiellement le scénario de transition décrit dans la documentation de Google .

Je veux partager mon expérience. Mon projet utilise Moxy et Cicerone, je trouve mon expérience intéressante, car dans les chaînes de télégramme officielles de ces bibliothèques, la question apparaît périodiquement quand seront-elles transférées vers Androidx.

Migrez simplement vers AndroidX ...

Pour transférer le projet vers Androidx, vous devez suivre quelques étapes simples:

1. Installez compileSdkVersion 28 et targetSdkVersion 28 , mettez à jour toutes les bibliothèques de support vers les dernières versions.

2. Dans le fichier gradle.properties , ajoutez les lignes:

android.useAndroidX=true android.enableJetifier=true 

3. Si vous utilisez déjà Android Studio 3.2, utilisez le refactoring:


Il fera la plupart (ou moins) du travail pour vous.

Si, pour une raison quelconque, vous n'utilisez pas Git ou un autre système de contrôle de version, à ce stade, vous aurez la possibilité de créer une archive de projet:


Cliquez sur le bouton Migrer, sélectionnez où enregistrer l'archive, et après un certain temps, nous obtenons le résultat de la vérification du projet avant la refactorisation:


Nous voyons ici quelles dépendances dans build.gradle et dans les directives d'importation seront remplacées. Dans l'exemple de la classe MainActivity, comme on peut le voir sur la capture d'écran ci-dessus, une dépendance sera remplacée: android.support.v4.view.GravityCompat , mais si nous ouvrons cette classe, nous verrons qu'il y a en fait trois autres dépendances qui doivent être remplacées:


Je n'ai pas compris la raison d'un tel comportement sélectif, mais ces dépendances devront être corrigées manuellement. Cliquez sur "Refactoriser".


Donc, comme le studio n'a pas pu remplacer toutes les dépendances (peut-être que vous pourriez, alors vous pouvez être félicité), lorsque vous essayez de construire un projet, vous verrez une liste d'erreurs similaire:


En ouvrant la classe avec des erreurs, nous verrons quelque chose comme ceci:


Nous supprimons les dépendances obsolètes, et par raccourci clavier Alt + Entrée, nous importons des classes du package androidx


Ainsi, nous fixons toutes les classes. Si l'erreur n'est pas liée à l '«importation», n'y prêtez pas attention, elle est probablement due aux mêmes problèmes dans une autre classe.

Par exemple:


Les erreurs ici sont liées au fait que dans la classe TimelineView, vous devez également éliminer les problèmes d'importation. Lorsque toutes les erreurs sont corrigées, nous exécutons à nouveau la construction du projet, et peut-être que nous obtenons à nouveau la liste des erreurs, uniquement dans les autres classes, nous continuons le processus itératif.

Pour les erreurs avec les classes générées (Dagger ou DataBinding), ne faites pas attention à ce stade. S'il n'y a pas d'erreurs dans vos classes et que le studio ne jure qu'au code généré, vous devez exécuter le projet Clean and Rebuild Project.


Si cela n'aide pas, vous pouvez essayer de vider le cache du studio:


Vous devrez vider le cache au moins une fois, afin que les classes qui génèrent DataBinding ou Room soient correctement créées.

Bibliothèques externes

En général, nous définissons l'indicateur android.enableJetifier = true juste pour qu'au stade de la construction du projet, les dépendances des bibliothèques externes soient remplacées automatiquement par les dépendances AndroidX correspondantes, mais pour une raison quelconque, cela ne se produit pas.

Dans tous les cas, avant de faire ce qui est décrit ci-dessous, assurez-vous que vous avez ce problème et que les dernières versions des bibliothèques que vous utilisez n'ont pas encore été traduites vers AndroidX.

Moxy

MainActivity dans mon projet est hérité de MvpAppCompatActivity est la classe Moxy, qui, au moment de la rédaction, n'a pas encore été traduite en AndroidX. Pour résoudre ce problème, j'ai copié la classe dans mon projet, dans un package androidx distinct, et y ai corrigé les dépendances. Il vaut mieux laisser le nom de la classe inchangé, il sera donc plus facile de mettre à jour les dépendances.

La même procédure doit être effectuée pour les fragments, pour la classe MvpAppCompatFragment .

Veuillez noter qu'il existe un générique dans ces classes, dans le champ mMvpDelegate , n'oubliez pas d'y corriger la dépendance, il est facile de ne pas le remarquer, car il s'agit d'une dépendance à la classe Moxy, et non à la classe de bibliothèque de support.

Cicerone

Pour résoudre des problèmes avec Cicerone, j'ai dû créer une copie des classes SupportAppScreen et SupportAppNavigator dans mon projet. Notez que la classe SupportAppNavigator dépend de SupportAppScreen. N'oubliez pas de corriger cette dépendance sur votre copie.

Conclusions

Passer à AndroidX est une expérience passionnante, et peut-être que si vous n'avez pas un besoin urgent, vous devriez attendre un peu avec. Après tout, alors, lorsque la plupart du râteau sera retiré de votre chemin, il sera plus facile et plus rapide de le faire. Mais personnellement, je suis heureux que ce chemin soit passé, les bosses sur le front guérissent et l'expérience utile restera avec moi.