Über das Problem der Inkompatibilität nach dem Hinzufügen von Fragmenten in Android

Entstehung und Einführung von Fragment

Android läuft auf einer Vielzahl von Geräten, von kleinen Handys bis zu großen Tablets und sogar Fernsehern. Angesichts der Unterschiede in der Bildschirmgröße wird in vielen Fällen zuerst eine App für Handys entwickelt und dann eine Kopie erstellt, um die Layouts zu ändern, um Tablets und anderen großen Bildschirmen anzupassen. Kann man nicht eine App entwickeln, die gleichzeitig auf Handys und Tablets funktioniert? Natürlich, das muss es geben. Der Aufkommen von Fragmenten ist dazu da, dieses Problem zu lösen. Man kann Fragment als Bestandteil einer Activity-Oberfläche betrachten, und die Oberfläche einer Activity kann sogar vollständig aus Fragmenten bestehen. Noch cooler ist, dass Fragment ihren eigenen Lebenszyklus und die Möglichkeit haben, Benutzerereignisse zu empfangen und zu verarbeiten, sodass man nicht in der Activity viele Codezeilen für die Ereignisbehandlung der Steuerelemente schreiben muss. Wichtiger noch ist, dass man Fragment dynamisch hinzufügen, ersetzen und entfernen kann.

Gestern habe ich etwas über Android Fragments gelernt. Nach den Anweisungen auf der offiziellen Website habe ich eine Klasse BlankFragment erstellt, die von Fragment abgeleitet ist. Beim Kompilieren trat jedoch ein Fehler auf:

Fehler: Ausführung fehlgeschlagen für Aufgabe ':app:processDebugManifest'.
> Fehlschlag des Manifest-Mergers : Attribut meta-data#android.support.VERSION@value value=(26.0.0-beta1) von [com.android.support:design:26.0.0-beta1] AndroidManifest.xml:28:13-41
  ist auch im [com.android.support:support-v4:26.1.0] AndroidManifest.xml:28:13-35 value=(26.1.0).
  Vorschlag: Fügen Sie 'tools:replace="android:value"' zu <meta-data> Element in AndroidManifest.xml:26:9-28:44 um zu überschreiben.

Nach einem kurzen Suchen gibt es viele verschiedene Meinungen. Die unzuverlässigste davon ist, dass man die Tags im Manifest-Datei von android:name auf class ändern soll. Aus den Protokollen ist klar, dass es mit der Version zu tun hat! Später fand ich schließlich eine Lösung, die mit der Version kompatibel ist, und man muss den folgenden Code in build.gradle im app-Verzeichnis hinzufügen:

configurations.all {}}
  resolutionStrategy.eachDependency { DependencyResolveDetails details ->
    def requested = details.requested
    if (requested.group == 'com.android.support') {
      if (!requested.name.startsWith("multidex")) {
        details.useVersion '26.0.0-beta1'
      }
    }
  }
}

Es hat tatsächlich funktioniert. Aber das reicht nicht aus.

Beachtet, direkt über diesem hinzugefügten Code wird beschrieben, welche Bibliotheken die Projektabhängigkeiten sind:

dependencies {
  Implementierung fileTree(dir: 'libs', include: ['*.jar'])
  Implementierung 'com.android.support:appcompat-v7:26.0.0-beta1'
  Implementierung 'com.android.support.constraint:constraint-layout:1.0.2'
  Implementierung 'com.android.support:design:26.0.0-beta1'
  Implementierung 'com.android.support:support-v4:26.1.0'
  testImplementation 'junit:junit:4.12'
  androidTestImplementation 'com.android.support.test:runner:0.5'
  androidTestImplementation 'com.android.support.test.espresso:espresso-core:2.2.2'
}

Und unter diesem Zeilen ist eine Rote Linie:

Implementierung 'com.android.support:appcompat-v7:26.0.0-beta1'

Mauszeiger darauf anzeigen:

Alle com.android.support-Bibliotheken müssen die gleiche Versionsbeschreibung verwenden 
(die Mischung von Versionen kann zu Runtime-Crashes führen). 
Gefundene Versionen 26.1.0, 26.0.0-beta1. Beispielen gehören com.android.support:support-compat:26.1.0 
und com.android.support:animated-vector-drawable:26.0.0-beta1

Das ist sehr klar gesagt: Alle Bibliotheken, die com.android.support abhängig sind, müssen die gleiche Version verwenden! Schauen wir uns den Dependency-Bereich an, com.android.support:appcompat-v7:26.0.0-beta1und com.android.support:support-v4:26.1.0 zwei Versionen sind gegensätzlich! Schauen wir uns die Git-Aufzeichnungen an,26.1.0 diese Zeile ist neu hinzugefügt, muss sicherlich sein, wenn BlankFragment-Klasse neu erstellt wurde, wird AndroidStudio automatisch hinzugefügt. Gehen wir zurück und schauen wir uns das Fehlerprotokoll an, spricht es nicht auch denselben Sinn aus?

Ich muss über AndroidStudio meckern. Wenn du automatisch Versionen abhängigkeiten hinzufügen willst, überprüfe auch die Kompatibilität. Ansonsten wäre es besser, es nicht hinzuzufügen, lassen Sie uns selbst machen. Ich hasse diese halbautomatischen Dinge am meisten, sie sind am schlimmsten.

Außerdem ist die Syntax der gradle-Datei auch sehr interessant. Die Kommentare sind im Stil von C/C++Das Stil, die Funktionsdeklaration ist im Stil von Python, Lambda-Ausdrücke erinnern ein bisschen an C#.

Zusammenfassung

Die oben genannten sind von mir vorgestellten Informationen über das Problem der Inkompatibilität nach dem Hinzufügen von Fragmenten in Android, hoffe, dass sie Ihnen helfen. Wenn Sie irgendwelche Fragen haben, hinterlassen Sie bitte eine Nachricht, ich werde Ihnen so schnell wie möglich antworten. Ich möchte auch sehr danken, dass Sie die Unterstützung der Website Anleitungshandbuch zeigen!

Erklärung: Der Inhalt dieses Artikels wurde aus dem Internet übernommen und gehört dem Urheberrecht des jeweiligen Autors. Der Inhalt wurde von Internetnutzern freiwillig beigesteuert und hochgeladen. Diese Website besitzt keine Eigentumsrechte und hat den Inhalt nicht von Hand bearbeitet. Sie übernimmt keine rechtlichen Verantwortlichkeiten. Wenn Sie verdächtigen Inhalt entdecken, sind Sie herzlich eingeladen, eine E-Mail an notice#w zu senden.3codebox.com (Bitte ersetzen Sie # durch @, wenn Sie eine E-Mail senden, um zu melden, und fügen Sie relevante Beweise bei. Sobald überprüft, wird diese Website den verdächtigen Inhalt sofort löschen.)