Eine Aktivität und alle anderen Fragmente [geschlossen]

158

Ich denke da an mit einem Bildschirm Implementierung Activityund alle anderen sreens mit Fragmentsund managing all the fragments thru the activity.

Ist es eine gute Idee? und meine Antwort ist NEIN, aber ich möchte trotzdem klarer über diesen Gedanken Bescheid wissen.

Was sind die Vor- und Nachteile der Idee?

Hinweis:

Bitte geben Sie mir nicht den Link für Fragment und Aktivität.

BEARBEITEN:

Hier ist etwas über Fragmente und Aktivität:

Vorteile:

  1. Fragmente sollen mit Aktivitäten als Unteraktivität verwendet werden.
  2. Fragmente sind kein Ersatz für Aktivitäten.
  3. Fragmente sind für die Wiederverwendbarkeit gedacht (Sie müssen wissen, auf welche Weise Wiederverwendbarkeit erreicht werden kann.).
  4. Fragmente sind der beste Weg, um Code zu schreiben, der sowohl Tablets als auch Telefone unterstützt.

Nachteile:

  1. Wir müssen die Schnittstelle implementieren, um die Daten aus Fragmenten zu erhalten.
  2. Für den Dialog müssen wir einen langen Weg gehen, um ihn zu zeigen.

Warum sollten wir Fragmente verwenden, wenn wir keine Tabletten in Betracht ziehen? Was ist der Startzeitunterschied zwischen Aktivität und Fragment?

Vineet Shukla
quelle
Können Sie näher erläutern, warum Sie der Meinung sind, dass die Antwort Nein lautet? Ich bin nicht einverstanden, aber es ist einfacher, Bedenken auszuräumen, die Sie möglicherweise bezüglich dieses Ansatzes haben, wenn wir wissen, was diese Bedenken sind.
Alexander Lucas
1
@AlexanderLucas Die Antwort, die ich mit Nein gegeben habe, weil dies Ihren Code weniger modular macht und die Komplexität erhöht.
Vineet Shukla
@Ski Sie konzentrieren sich mehr darauf, Ihre Antwort zu akzeptieren. Bitte konzentrieren Sie sich darauf, was gefragt wird und welche Antwort die beste sein sollte, die Sie geben können.
Vineet Shukla
3
Für alle, die dies finden, habe ich den Refactor gestoppt, weil die Dinge sehr schnell sehr kompliziert wurden.
Theblang
18
Dies ist eine gute Frage und hätte nicht geschlossen werden dürfen.
Jim In Texas

Antworten:

94

Dies hängt von der App ab, die Sie erstellen. Ich habe mehrere Apps mit beiden Ansätzen erstellt und kann nicht sagen, dass ein Weg immer besser ist als der andere. In der neuesten App, die ich erstellt habe, habe ich den Single- ActivityAnsatz und eine Navigation im Facebook-Stil verwendet. Bei der Auswahl von Elementen aus der Navigationsliste aktualisiere ich einen einzelnen FragmentContainer, um diesen Abschnitt anzuzeigen.

Das heißt, eine Single zu haben, bringt Activityauch eine Menge Komplexität mit sich. Angenommen, Sie haben ein Bearbeitungsformular, und für einige der Elemente, die der Benutzer auswählen oder erstellen muss, müssen sie zu einem neuen Bildschirm wechseln. Bei Aktivitäten würden wir nur den neuen Bildschirm mit aufrufen, startActivityForResultaber mit Fragmentsgibt es so etwas nicht, sodass Sie am Ende den Wert auf dem speichern Activityund das Hauptbearbeitungsfragment überprüfen lassen Activity, ob Daten ausgewählt wurden und dem Benutzer angezeigt werden sollen.

Was Aravind über das Festhalten an einem einzigen ActivityTyp sagt, ist ebenfalls wahr, aber nicht wirklich so einschränkend. Ihre Aktivität wäre eine FragmentActivity und solange Sie keine benötigen, MapViewgibt es keine wirklichen Einschränkungen. Wenn Sie zwar Karten anzeigen möchten, können Sie dies tun, aber Sie müssen entweder die Android-Kompatibilitätsbibliothek ändern, um sie zu FragmentActivityerweitern, MapActivityoder die öffentlich verfügbaren Android-Support-v4-Google-Karten verwenden .

Letztendlich sind die meisten Entwickler, von denen ich weiß, dass sie den einen ActivityWeg gegangen sind, zu mehreren Aktivitäten zurückgekehrt, um ihren Code zu vereinfachen. In Bezug auf die Benutzeroberfläche stecken Sie auf einem Tablet manchmal fest, wenn Sie Activitynur eine verwenden, um die verrückte Interaktion zu erreichen, die Ihre Designer sich einfallen lassen :)

- BEARBEITEN -

Google hat endlich MapFragmentdie Kompatibilitätsbibliothek freigegeben , sodass Sie den android-support-v4-googlemaps-Hack nicht mehr verwenden müssen. Lesen Sie hier mehr über das Update: Google Maps Android API v2

- BEARBEITEN 2 -

Ich habe gerade diesen großartigen Beitrag über den modernen Zustand von Fragmenten (2017) gelesen und mich an diese alte Antwort erinnert. Ich dachte, ich würde teilen: Fragmente: Die Lösung für alle Probleme von Android

Justin Morris
quelle
6
Es gibt settargetfragmentund Sie könnten die Aktivität wie startforresultVerfahren behandeln.
Lalith B
1
Meiner Meinung nach gibt es Aktivitäten nur, weil es das alte System ist. Fragment gab es vorher nicht. Es gibt wirklich nichts, was Aktivitäten können und Fragmente nicht, außer Formalitäten. Ich könnte mir sogar vorstellen, dass irgendwann Aktivitäten entfernt werden und alles ein Fragment ist.
Ixx
1
Wenn Sie die Nachteile von Fragmenten zusammenfassen, die Sie nur geben, gibt es eigentlich keine. startActivityForResult hat, wie Lalith B sagt, ein Gegenstück, und Karten sind ebenfalls kein Problem. Außerdem kann alles (Speicherstatus usw.) mit den Lebenszyklusmethoden des Fragments behandelt werden.
Ixx
85

Ich bin dabei, ein Projekt (5 Monate in der Entwicklung) abzuschließen, das 1 Aktivität und 17 Fragmente im Vollbildmodus enthält. Dies ist mein zweites fragmentbasiertes Projekt (vorher waren es 4 Monate).

Vorteile

  • Die Hauptaktivität besteht aus 700 Codezeilen, die die Reihenfolge der Fragmentnavigation genau verwalten.
  • Jedes Fragment ist schön in eine eigene Klasse unterteilt und relativ klein (~ ein paar hundert Zeilen UI-Material).
  • Das Management kann sagen: "Hey, wie wäre es, wenn wir die Reihenfolge dieser Bildschirme ändern?", Und ich kann es sehr einfach tun, da diese Fragmente nicht voneinander abhängen, sondern alle über die Aktivität kommunizieren. Ich muss nicht durch einzelne Aktivitäten graben, um herauszufinden, wo sie sich gegenseitig anrufen.
  • Meine App ist sehr grafikintensiv und würde niemals als 1 Bildschirm 1 Aktivität funktionieren. All diese Unteraktivitäten im Speicher würden dazu führen, dass der App die ganze Zeit der Speicher ausgeht, also müsste ichfinish() alle nicht sichtbaren Aktivitäten und dieselbe Steuerlogik für die Navigation erstellen müsste, wie ich es bei Fragmenten tun würde. Könnte es auch nur deshalb mit Fragmenten machen.
  • Wenn wir jemals eine Tablet-App machen, fällt es uns leichter, Dinge neu zu faktorisieren, da bereits alles gut getrennt ist.

Nachteile

  • Man muss lernen, wie man Fragmente benutzt
Tamas
quelle
1
Ich war mir nicht sicher, ob ich zu viele Fragmente und erst jetzt Aktivitäten hatte ... irgendwelche Probleme mit der Produktion, und die Schuld liegt bei Ihnen !! :)
Shahar
1
@ Dinash lass das Betriebssystem deine Aktivität nicht neu starten. Behandeln Sie die Orientierungsänderung selbst. Lesen Sie hier mehr: stackoverflow.com/questions/5913130/…
Tamas
1
@Tamas Hattest du Multi-Fragment-Bildschirme (zB Master-Detail) und wenn ja, wie hast du damit umgegangen?
Theblang
7
@Tamas Dieser Ansatz ist stark gegen Android. Sie landen in der GOTT-Klasse. Das Android-System ist für die Arbeit mit Aktivitäten ausgelegt - z. B. haben Sie keine gute Möglichkeit, Symbolleisten in mehreren Fragmenten zu handhaben. Sie haben kein Startfragment für das Ergebnis und viele weitere haben es nicht. Das heißt, Sie müssen die gesamte Logik, die bereits vorhanden ist, neu schreiben. Was ist mit lokalen Rundfunkempfängern, Diensten und anderen Android-Komponenten? Um einen Dienst zu starten, müssen Sie Folgendes tun: getActivity ()! = Null ... das ist wirklich hässlich. Auch die Kommunikation zwischen Fragmenten ist sehr seltsam, wenn Sie viel fr haben.
Teodor
9
700 Zeilen !!!! "schön"???? Der Unterricht ist kostenlos.
Beplaya
16

Stellen Sie zunächst sicher, dass Sie ein modulares Design mit Modell, Ansicht und Präsentator haben, das nicht stark von einer Aktivität oder einem Fragment abhängig ist.

Was bieten Aktivitäten und Fragmente wirklich?

  1. Lebenszyklusereignisse und Backstack
  2. Kontext und Ressourcen

Verwenden Sie sie daher NUR dafür . Sie haben genug Verantwortung, machen sie nicht zu kompliziert. Ich würde argumentieren, dass selbst das Intantiieren einer Textansicht in einer Aktivität oder einem Fragment eine schlechte Praxis ist. Es gibt einen Grund Methoden wie öffentliche Ansicht findViewById (int id) sind PUBLIC .

Jetzt wird die Frage einfacher: Benötige ich mehrere unabhängige Lebenszyklusereignisse und Backstacks? Wenn Sie ja vielleicht denken, verwenden Sie Fragmente. Wenn Sie niemals denken, verwenden Sie keine Fragmente.

Am Ende könnten Sie Ihren eigenen Backstack und Lebenszyklus erstellen. Aber warum das Rad neu erstellen?

EDIT: Warum dies abstimmen? Einzelzweckklassen Leute! Jede Aktivität oder jedes Fragment sollte in der Lage sein, einen Präsentator zu instanziieren, der eine Ansicht instanziiert. Der Präsentator und die Ansicht sind ein Modul, das ausgetauscht werden kann. Warum sollte eine Aktivität oder ein Fragment die Verantwortung eines Moderators haben?

beplaya
quelle
Hm ... der Zusammenhang zwischen dem Instanziieren einer Ansicht als schlechte Vorgehensweise und findViewById () public ist unklar. Obwohl ich der Instanziierung von Ansichten zustimme, halte ich das Aufrufen von findViewById aus einer anderen Klasse (z. B. die Aktivität, die ein Fragment hostet, für das Fragment) für eine schlechte Praxis. Ich weiß nicht genau, warum dies öffentlich ist, da dies zumindest in den Fällen, die ich mir vorstellen kann, zu chaotischem Code und nicht zu modularem Design führt.
Ixx
IMHO: Wenn Sie Ihrer Ansicht und Ihrem Präsentator eine Aktivität übergeben (indem Sie die 2 zusammen als "Modul" bezeichnen), können Sie dieses Modul ohne andere Aktivitäten wiederverwenden. Wenn es hilft, kann es am besten sein, die Aktivität als eine Schnittstelle zu übergeben, die nur die notwendigen Dinge enthüllt. Wenn Sie es hassen, Ansichten außerhalb der Aktivität zu finden, können Sie alle Ansichten über diese Schnittstelle in die pres./view einfügen. Hauptpunkt ist, dass ich glaube, dass Android-Codierung außerhalb des Konzepts von Aktivitäten und Frags erfolgen sollte, so dass das Wechseln zwischen den beiden einfach ist. Dann wird klar, was am besten ist und Sie nicht mit dem einen oder anderen in einem Netz von stecken Code.
Beplaya
3
Lassen Sie das MVP los, Sie werden ohne Android besser dran sein. Sie können viel Zeit damit verbringen, einen bestimmten Formblock durch ein Loch zu passen, das eine andere Form hat. Sicher, es ist eine Herausforderung, aber es gibt wahrscheinlich funktionale Anforderungen, für die Sie klüger wären.
Straya
12

Vorteile

Sie können Ihre Fragmente von einer einzigen Aktivität aus steuern, da alle Fragmente unabhängig voneinander sind. Die Fragmente haben einen Lebenszyklus ( onPause, onCreate, onStart...) ihre eigenen. Durch einen Lebenszyklus können Fragmente unabhängig auf Ereignisse reagieren und ihren Status durch speichernonSaveInstanceState und zurückgebracht werden (z. B. wenn sie nach einem eingehenden Anruf fortgesetzt werden oder wenn der Benutzer auf die Schaltfläche "Zurück" klickt).

Nachteile

  1. Erstellen Sie Komplexität in Ihrem Aktivitätscode.
  2. Sie müssen die Reihenfolge der Fragmente verwalten.

Trotzdem ist es eine gute Idee, als müssten Sie eine App erstellen, in der Sie mehrere Ansichten anzeigen möchten. Mit dieser Idee können Sie mehrere Fragmente in einer einzigen Ansicht anzeigen.

Sahil Mahajan Mj
quelle
2

Dies hängt vom Design Ihrer App ab. Angenommen, wenn Sie Registerkarten in ActionBar im Entwurfslayout verwenden, können in der Einzelaktivität der App Fragmente beim Klicken auf die Registerkarte geändert werden. Jetzt haben Sie eine Aktivität und nehmen an, drei Registerkarten in der Aktionsleiste und die Ansicht für die Registerkarten, die von den Fragmenten bereitgestellt werden, was die Verwaltung von Plus erleichtert, ist ebenfalls möglich. Es hängt also alles vom Designschema Ihrer App ab und davon, wie Sie die Entscheidung treffen, dafür zu bauen.

ASCHE
quelle
1

Vorteile:

  • Kann verwendet werden, um eine einzelne Oberfläche zu erstellen, die von mehreren Bildschirmgrößen und -ausrichtungen über XML-Layouts verwendet werden kann.

Nachteile:

  • Erfordert komplexeren Code in Ihrer Aktivität.

Ich halte dies für eine gute Idee, da die Verwendung unterschiedlicher XML-Layouts basierend auf der aktuellen Bildschirmgröße und -ausrichtung die Benutzerfreundlichkeit der App verbessern und die Notwendigkeit verringern kann, mehrere Versionen Ihrer App freizugeben, wenn Sie Ihre App sowohl für Telefone als auch für Tablets freigeben möchten. Wenn Ihre App niemals von Tablets und Handys verwendet wird, ist es wahrscheinlich nicht die Mühe wert.

Ski
quelle
Zur Orientierung ist es nicht erforderlich, unterschiedliche XML-basierte Layouts zu verwenden.
Vineet Shukla
@VineetShukla stimmt, aber es ist eine Option, genau wie die Verwendung verschiedener XML-Layouts basierend auf der Bildschirmgröße. Beispielsweise hat der Startbildschirm meines Android-Telefons ein anderes Layout, wenn ich ihn im Querformat oder im Hochformat ansehe.
Ski
0

Ich bin ein Befürworter der Verschiebung der Gesamtinflation auf Fragmente, um eine bessere Flexibilität zu gewährleisten. Zum Beispiel eine einzige Landeaktivität für ein Tablet, das mehrere Fragmente zusammenfasst und dieselben Fragmente auf einem Telefon wiederverwendet, um einen Bildschirm pro Fragment anzuzeigen. In der Telefonimplementierung hätte ich jedoch für jeden Bildschirm eine eigene Aktivität. Die Aktivitäten hätten nicht zu viel Code, da sie sich sofort ihrem fragmentierten Gegenstück zur Ansicht der Inflation unterwerfen würden.

Ich denke, es ist eine schlechte Idee für die Telefonimplementierung, zu einer einzelnen Landeaktivität wechseln zu müssen, wenn Registerkarten oder ein ausziehbares Menü eingeführt werden, da die Registerkarten- oder Menünavigation nur zu einem völlig neuen Bildschirm führt.

user1679130
quelle
"Ich denke, es ist eine schlechte Idee für die Telefonimplementierung, zu einer einzelnen Landeaktivität wechseln zu müssen, wenn Registerkarten oder ein ausziehbares Menü eingeführt werden, da die Registerkarten- oder Menünavigation nur zu einem völlig neuen Bildschirm führt." -> Es ist nicht verständlich, was genau Sie meinen, aber in einer App mit nur einer Aktivität (Tablet / Telefon) sind weder Registerkarten noch Seitenmenüs ein Problem.
Ixx
-1

Der wichtigste Grund, den ich für die Nichtverwendung des Einzelaktivitätsansatzes angeben würde, ist, dass der Aktivitätslebenszyklus genutzt werden kann. Aktivitäten enthalten das Kontextverhalten eines bestimmten Teils der Anwendung, und Fragmente ergänzen dieses Verhalten. Die Möglichkeit, die überschreibbaren Schritte im Aktivitätslebenszyklus zu nutzen, hilft, das Verhalten einer Aktivität mit Methoden wie onPauseund von einem anderen zu trennen onResume. In diesem Lebenszyklus können Sie auch zum vorherigen Kontext zurückkehren. Beim Einzelaktivitätsansatz müssen Sie nach dem Verlassen eines Fragments einen Mechanismus erstellen, um zu diesem zurückzukehren.

japino
quelle
4
Ich glaube nicht, dass das wahr ist. Aus der Dokumentation zum Fragmentlebenszyklus ( developer.android.com/guide/components/fragments.html#Lifecycle ): "Der Lebenszyklus der Aktivität, in der das Fragment lebt, wirkt sich direkt auf den Lebenszyklus des Fragments aus, sodass jeder Lebenszyklus für die Aktivität zurückgerufen wird führt zu einem ähnlichen Rückruf für jedes Fragment. Wenn die Aktivität beispielsweise onPause () empfängt, erhält jedes Fragment in der Aktivität onPause (). "
Ski