Wechseln Sie zu Androidx oder einem aufregenden Rake-Abenteuer

Das Thema des Übergangs zu Androidx liegt nun in der Luft. Es gibt bereits einen kurzen Artikel in englischer Sprache von Daniel Lew , es gibt einen Bericht . Alle betrachten das in der Google-Dokumentation beschriebene Übergangsszenario jedoch eher oberflächlich.

Ich möchte meine Erfahrungen teilen. Mein Projekt verwendet Moxy und Cicerone. Ich finde meine Erfahrung interessant, da in den offiziellen Telegrammkanälen dieser Bibliotheken regelmäßig die Frage auftaucht, wann sie auf Androidx übertragen werden.

Einfach auf AndroidX migrieren ...


Um das Projekt auf Androidx zu übertragen, müssen Sie einige einfache Schritte ausführen:

1. Installieren Sie compileSdkVersion 28 und targetSdkVersion 28 und aktualisieren Sie alle Support-Bibliotheken auf die neuesten Versionen.

2. Fügen Sie in der Datei gradle.properties die folgenden Zeilen hinzu:

android.useAndroidX=true android.enableJetifier=true 

3. Wenn Sie bereits Android Studio 3.2 verwenden, verwenden Sie Refactoring:


Er wird den größten Teil (oder weniger) der Arbeit für Sie erledigen.

Wenn Sie aus irgendeinem Grund kein Git oder ein anderes Versionskontrollsystem verwenden, haben Sie zu diesem Zeitpunkt die Möglichkeit, ein Projektarchiv zu erstellen:


Klicken Sie auf die Schaltfläche Migrieren, wählen Sie aus, wo das Archiv gespeichert werden soll, und nach einer Weile erhalten wir das Ergebnis der Überprüfung des Projekts vor dem Refactoring:


Hier sehen wir, welche Abhängigkeiten in build.gradle und in Importanweisungen ersetzt werden. Im Beispiel der MainActivity-Klasse wird, wie im obigen Screenshot zu sehen ist, eine Abhängigkeit ersetzt: android.support.v4.view.GravityCompat . Wenn wir diese Klasse öffnen, werden wir feststellen , dass tatsächlich drei weitere Abhängigkeiten ersetzt werden müssen:


Ich habe den Grund für dieses selektive Verhalten nicht verstanden, aber diese Abhängigkeiten müssen manuell behoben werden. Klicken Sie auf "Refactor ausführen".

Wenn Sie Android Studio 3.2 nicht verwenden, werden alle Abhängigkeiten manuell korrigiert
Die Abhängigkeiten in build.gradle müssen geändert werden (aus Gründen der Übersichtlichkeit habe ich die alten Abhängigkeiten auskommentiert ):



Eine vollständige Liste der Ersatzprodukte finden Sie hier .

Synchronisieren Sie dann das Projekt mit Gradle und erhalten Sie eine Reihe von Fehlern. Dies sind Importanweisungen in Ihren Klassen. Sie beziehen sich auf alte Pakete. Sie müssen sie gemäß dieser Tabelle ändern.

Da das Studio nicht alle Abhängigkeiten ersetzen konnte (vielleicht könnten Sie, dann können Sie gratulieren), wird beim Versuch, ein Projekt zu erstellen, eine ähnliche Liste von Fehlern angezeigt:


Wenn wir die Klasse mit Fehlern öffnen, sehen wir ungefähr Folgendes:


Wir entfernen veraltete Abhängigkeiten und importieren mit dem Hotkey Alt + Enter Klassen aus dem AndroidX- Paket


Somit fixieren wir alle Klassen. Wenn der Fehler nicht mit „Importieren“ zusammenhängt, beachten Sie ihn nicht. Höchstwahrscheinlich liegt er an denselben Problemen in einer anderen Klasse.

Zum Beispiel:


Die Fehler hier hängen damit zusammen, dass Sie in der TimelineView-Klasse auch Importprobleme beseitigen müssen. Wenn alle Fehler behoben sind, führen wir die Projekterstellung erneut aus, und möglicherweise erhalten wir die Fehlerliste erneut. Nur in anderen Klassen setzen wir den iterativen Prozess fort.

Achten Sie bei Fehlern mit generierten Klassen (Dolch oder Datenbindung) zu diesem Zeitpunkt nicht darauf. Wenn Ihre Klassen keine Fehler enthalten und das Studio nur auf den generierten Code schwört, müssen Sie das Projekt "Projekt bereinigen" und "Projekt neu erstellen" ausführen.


Wenn dies nicht hilft, können Sie versuchen, den Studio-Cache zu leeren:


Sie müssen den Cache mindestens einmal leeren, damit die Klassen, die die Datenbindung oder den Raum generieren, korrekt erstellt werden.

Externe Bibliotheken


Im Allgemeinen setzen wir das Flag android.enableJetifier = true, damit in der Phase der Projekterstellung die Abhängigkeiten externer Bibliotheken automatisch durch die entsprechenden AndroidX-Abhängigkeiten ersetzt werden. Aus irgendeinem Grund geschieht dies jedoch nicht.

Bevor Sie die unten beschriebenen Schritte ausführen, stellen Sie auf jeden Fall sicher, dass Sie dieses Problem haben und dass die neuesten Versionen der von Ihnen verwendeten Bibliotheken noch nicht in AndroidX übersetzt wurden.

Moxy


MainActivity in meinem Projekt wurde von MvpAppCompatActivity geerbt. Dies ist die Moxy-Klasse, die zum Zeitpunkt des Schreibens noch nicht in AndroidX übersetzt wurde. Um dieses Problem zu lösen, habe ich die Klasse in einem separaten AndroidX- Paket in mein Projekt kopiert und die Abhängigkeiten darin behoben. Der Klassenname bleibt besser unverändert, damit die Abhängigkeiten leichter aktualisiert werden können.

Das gleiche Verfahren muss für Fragmente für die MvpAppCompatFragment- Klasse durchgeführt werden.

Beachten Sie, dass diese Klassen im Feld mMvpDelegate ein Generikum enthalten. Vergessen Sie nicht, die Abhängigkeit darin zu korrigieren. Es ist leicht, sie nicht zu bemerken, da es sich um eine Abhängigkeit von der Moxy-Klasse und nicht von der Support-Bibliotheksklasse handelt.

Cicerone


Um Probleme mit Cicerone zu lösen, musste ich in meinem Projekt eine Kopie der Klassen SupportAppScreen und SupportAppNavigator erstellen. Beachten Sie, dass die SupportAppNavigator-Klasse von SupportAppScreen abhängig ist. Denken Sie daran, diese Abhängigkeit von Ihrer Kopie zu beheben.

Schlussfolgerungen


Der Wechsel zu AndroidX ist eine aufregende Erfahrung. Wenn Sie keinen dringenden Bedarf haben, sollten Sie ein wenig warten. Wenn der größte Teil des Rechens von Ihrem Pfad entfernt wird, ist dies schließlich einfacher und schneller. Aber ich persönlich freue mich, dass dieser Weg vorbei ist, die Unebenheiten auf der Stirn heilen und die nützliche Erfahrung bei mir bleiben wird.

Source: https://habr.com/ru/post/de430660/


All Articles