Eine Aktivität und alle anderen Fragmente [geschlossen]

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?

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

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

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?

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.

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.

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.

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.

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.