Ich habe seit ein paar Monaten android Apps erstellt und habe Probleme mit der beabsichtigten Verwendung von Fragments .
Fragments sollen wiederverwendbare UI-Komponenten sein, aber wie weit machen Sie sie allein?
Einer der von mir erstellten Fragments ist ein ListFragment von herunterladbaren Videos. Im Moment habe ich alle Methoden innerhalb des Fragment mit wenig oder keiner der Methoden implementiert, die den Host Activity aufrufen. Die Fragment ruft die Activity für ein paar kleinere Dinge auf, aber alles wie das Herunterladen von Dateien und das Auffinden von Dateien auf externen Speicher geschieht über Fragment .
90% der Zeit finde ich es die einfachste Art es zu implementieren, aber manchmal funktioniert es einfach nicht.
Ein Beispiel ist ein Bestätigungsdialog zum Löschen eines Videos in meinem ListFragment . Der Dialog ist ein DialogFragment , also ist er an die Activity angehängt, aber alle Methoden zum Aktualisieren und Löschen der Benutzeroberfläche befinden sich in ListFragment . Also habe ich am Ende die DialogFragment die Activity aufrufen, nur um die ListFragment aufzurufen.
Ein weiteres Beispiel ist die Bindung an ein Service . Verbinde ich Activity mit Service oder nur mit Fragment ? Die Activity hat keinen Nutzen für die Service , aber ist eine Fragment , die alle Arbeiten zum Starten und Pflegen von Service ausführen soll? Wenn nicht, bedeutet dies, dass alle Fragments Aufrufe an die Service durch die Activity gehen müssen, so dass die Fragment nicht länger allein steht.
Ich frage mich, ob ich die Stand-Alone-Idee zu weit nehme, ist ein Fragment stattdessen angeblich in sich abgeschlossen und verlässt sich tatsächlich auf die Activity , die es für all das schwere Heben hostet?
Danke für jede Hilfe.
Eine sehr interessante Frage!
Normalerweise versuche ich, meine Fragmente so isoliert wie möglich zu halten. Das bedeutet, dass ich sie normalerweise nicht über irgendetwas um sie herum weiß, außer für ihre eigene Aktivität. Es ist dann die Rolle der Aktivität (wenn Sie mich fragen), was immer das Fragment benötigt.
In der Praxis bedeutet dies, dass meine Fragmente niemals ihren eigenen Inhalt besitzen, wie etwa ein Inhaltsanbieter oder ein benutzerdefiniertes DAO. Die Aktivität (oder - Gott bewahre - die Anwendung) besitzt sie und stellt dann nur eine Teilmenge der Daten, wie einen Cursor, ein Domänenobjekt oder einen Adapter, für das Fragment bereit.
Dies bedeutet auch, dass wenn ein Fragment ein Element ändert, es die Aktivität auffordern muss, die Änderungen beizubehalten. Oder wenn ein Element gelöscht werden soll, muss das Fragment die Aktivität fragen, um die entsprechende UI für diese Operation anzuzeigen (ja, es ist technisch möglich, ein Fragment ein anderes Fragment anzeigen zu lassen, aber normalerweise versuche ich es so weit wie möglich zu vermeiden) .
Wenn es um Dienstleistungen geht und für sie verbindlich ist, weiß ich wirklich nicht, was ich vorschlagen soll, da es wirklich auf den Service und das, was es tut, ankommt. Wenn Sie in Ihrem Dienst neue Inhalte aus dem Internet herunterladen, scheint dies behoben zu sein, damit die Aktivität die Bindung verarbeiten kann (da die Aktivität die Daten gemäß der vorherigen Diskussion speichern muss). Wenn Sie andererseits basierend auf Ihren isolierten Daten (z. B. das Entschlüsseln einer Datei) etwas Bestimmtes berechnen, kann es sinnvoll sein, dass das Fragment diesen Teil behandelt.
In einer noch größeren Perspektive erkennt man bald, dass ein Setup, wie oben beschrieben, einige Callback-Interfaces entstehen lässt, da jedes Fragment einen Vertrag zu seiner Aktivität erstellen muss. Daher kommt es bei kleineren Projekten manchmal vor, dass ich meine eigenen Fragment-Pardigmen außer Kraft setze.
Ich kann auch nicht übersehen, dass meine Anwendungen bei der Verwendung von Fragmenten dazu neigen, in ihrer Architektur sehr MVC-orientiert zu sein. Ich überlasse es Ihnen und zukünftigen Lesern, zu entscheiden, ob es gut oder schlecht ist ;-)
Prost
Tags und Links android android-fragments