android example - Dilemma:Wann man Fragmente vs Aktivitäten verwendet:




beispiel tutorial (13)

Ich weiß, dass Activities einen einzelnen Bildschirm meiner Anwendung darstellen sollen, während Fragments als wiederverwendbare UI-Layouts mit darin eingebetteter Logik entworfen wurden.

Bis vor kurzem entwickelte ich eine Anwendung, wie sie sagte, dass sie entwickelt werden sollte. Ich habe eine Activity , die einen Bildschirm meiner Anwendung darstellt und Fragmente für ViewPager oder Google Maps . Ich habe selten eine ListFragment oder andere UI erstellt, die mehrmals wiederverwendet werden kann.

Kürzlich bin ich auf ein Projekt gestoßen, das nur 2 Activities enthält. Einer ist ein SettingsActivity und ein anderer ist MainActivity . Das Layout der MainActivity ist mit vielen versteckten Vollbild-UI-Fragmenten MainActivity und nur eines wird angezeigt. In der Acitivty Logik gibt es viele FragmentTransitions zwischen den verschiedenen Bildschirmen der Anwendung.

Was mir an diesem Ansatz gefallen hat, ist, dass die Anwendung eine ActionBar , sie bleibt intakt und bewegt sich nicht mit der Bildschirmwechselanimation, was beim Activity passiert. Dies verleiht diesen Bildschirmübergängen ein flüssigeres Gefühl.

Ich denke also, ich möchte Ihre derzeitige Entwicklungsweise bezüglich dieses Themas teilen, ich weiß, dass es auf den ersten Blick wie eine meinungsbasierte Frage aussieht, aber ich betrachte es als eine Android Design und Architektur Frage ... Nicht wirklich ein meinungsbezogen.

UPDATE (01.05.2014): Nach dieser Präsentation von Eric Burke von Square , (was ich sagen muss, ist eine großartige Präsentation mit vielen nützlichen Tools für Android-Entwickler. Und ich bin in keiner Weise verwandt mit Square)

http://www.infoq.com/presentations/Android-Design/

Aus meiner persönlichen Erfahrung in den letzten Monaten habe ich herausgefunden, dass der beste Weg, meine Anwendungen zu konstruieren, darin besteht, Gruppen von Fragmenten zu erstellen, die einen Fluss in der Anwendung darstellen und all diese Fragmente in einer Activity . Sie haben also in Ihrer Anwendung die gleiche Anzahl von Activities wie die Anzahl der Flüsse. Auf diese Weise bleibt die Aktionsleiste auf allen Bildschirmen des Ablaufs erhalten, wird aber beim Ändern eines Flusses neu erstellt, was sehr sinnvoll ist. Wie Eric Burke sagt und wie ich auch realisiert habe, ist die Philosophie, so wenig Activities wie möglich zu verwenden, nicht für alle Situationen anwendbar, weil sie eine Unordnung in dem schafft, was er die "Gott" -Aktivität nennt.


Answers

Was ich tat: Weniger Splitter wenn möglich. Leider ist es fast immer möglich. Ich habe also viele Fragmente und ein paar Aktivitäten. Einige Nachteile, die ich realisiert habe:

  • ActionBar & Menu: Wenn 2 Fragment hat einen anderen Titel, Menü, das
    wird schwer zu handhaben sein. Bsp .: Wenn Sie ein neues Fragment hinzufügen, können Sie den Titel der backstack ändern, aber wenn Sie es aus dem backstack gibt es keine Möglichkeit, den alten Titel wiederherzustellen. Möglicherweise benötigen Sie für jeden Fall eine Toolbar in jedem Fragment, aber lassen Sie mich glauben, dass Sie mehr Zeit dafür aufwenden werden.
  • Wenn wir startForResult benötigen, hat Aktivität aber das Fragment nicht.
  • Standardmäßig keine Übergangsanimation

Meine Lösung hierfür ist die Verwendung einer Aktivität zum Umbrechen eines Fragments. So haben wir separate startActivityForResult , Menü, startActivityForResult , Animation, ...


Der große Vorteil einer fragment over-Aktivität besteht darin, dass der Code, der für das Fragment verwendet wird, für verschiedene Aktivitäten verwendet werden kann. So wird die Wiederverwendbarkeit von Code in der Anwendungsentwicklung gewährleistet.


Ich benutze Fragmente für bessere Benutzererfahrung. Wenn Sie beispielsweise einen Button haben und einen Webservice ausführen möchten, indem Sie darauf klicken, hänge ich ein Fragment an die übergeordnete Aktivität an.

if (id == R.id.forecast) {

    ForecastFragment forecastFragment = new ForecastFragment();
    FragmentManager fm = getSupportFragmentManager();
    FragmentTransaction ft = fm.beginTransaction();
    ft.replace(R.id.main_content, forecastFragment);
    ft.addToBackStack("backstack");
    forecastFragment.setArguments(b);
    ft.commit();
}

Auf diese Weise muss der Benutzer nicht in eine andere Aktivität umziehen.

Und zweitens bevorzuge ich Fragmente, weil man sie während der Drehung leicht handhaben kann.


Experten werden Ihnen sagen: "Wenn ich die Benutzeroberfläche sehe, weiß ich, ob ich eine Activity oder ein Fragment ". Am Anfang wird das keinen Sinn haben, aber mit der Zeit werden Sie in der Lage sein zu sagen, ob Sie Fragment brauchen oder nicht.

Es gibt eine gute Praxis, die ich sehr hilfreich für mich gefunden habe. Es kam mir in den Sinn, als ich meiner Tochter etwas erklären wollte.

Stellen Sie sich eine Box vor, die einen Bildschirm darstellt. Kannst du einen anderen Bildschirm in dieses Feld laden? Wenn Sie eine neue Box verwenden, müssen Sie mehrere Elemente aus der ersten Box kopieren? Wenn die Antwort Ja lautet, sollten Sie Fragments , da die Activity alle duplizierten Elemente enthalten kann, um Ihnen beim Erstellen Zeit zu sparen, und Sie können Teile der Box einfach ersetzen.

Aber vergiss nicht, dass du immer einen Boxcontainer ( Activity ) brauchst oder deine Teile verteilt werden. Also eine Box mit Teilen drin.

Achten Sie darauf, die Box nicht zu missbrauchen. Android UX-Experten empfehlen (Sie können sie auf YouTube finden), wenn wir explizit eine andere Activity laden sollten, anstatt ein Fragment (wie wenn wir mit der Navigationsleiste arbeiten, die Kategorien enthält). Sobald Sie sich mit Fragments wohl fühlen, können Sie alle ihre Videos ansehen. Mehr noch, sie sind Pflichtmaterial.

Können Sie sich jetzt Ihre Benutzeroberfläche ansehen und herausfinden, ob Sie eine Activity oder ein Fragment benötigen? Hast du eine neue Perspektive bekommen? Ich denke du hast es getan.


Ich denke, die Verwendung von Fragmenten ist besser als die Verwendung von Aktivitäten, aber es ist schwierig, den Back-Stack-Button mithilfe von Fragment zu verwalten


Warum ich Fragment in allen Fällen über Aktivität bevorzuge.

  • Aktivität ist teuer. In Fragment werden Ansichten und Eigenschaftszustände getrennt. Wenn ein Fragment im backstack , werden seine Ansichten zerstört. Sie können also viel mehr Fragmente als Aktivität stapeln.

  • Backstack Manipulation. Mit FragmentManager ist es einfach, alle Fragmente zu löschen, mehr als auf Fragmente und Etcs einzufügen. Aber für Activity wird es ein Albtraum sein, diese Sachen zu manipulieren.

  • Ein viel vorhersehbarer Lebenszyklus . Solange die Host-Aktivität nicht wiederverwendet wird. Die Fragmente im Backstack werden nicht recycelt. So ist es möglich mit FragmentManager::getFragments() bestimmte Fragmente zu finden (nicht FragmentManager::getFragments() ).


Es gibt mehr, als Sie wissen, Sie müssen sich daran erinnern, dass eine Aktivität, die gestartet wird, nicht implizit die aufrufende Aktivität zerstört. Sicher, Sie können es so einrichten, dass Ihr Benutzer auf eine Schaltfläche klickt, um zu einer Seite zu gelangen. Sie starten die Aktivität dieser Seite und zerstören die aktuelle Seite. Dies verursacht eine Menge Overhead. Der beste Führer, den ich Ihnen geben kann, ist:

** Starten Sie eine neue Aktivität nur dann, wenn es sinnvoll ist, die Hauptaktivität und diese gleichzeitig geöffnet zu haben (denken Sie an mehrere Fenster).

Ein gutes Beispiel dafür, wann mehrere Aktivitäten sinnvoll sind, ist Google Drive. Die Hauptaktivität bietet einen Datei-Explorer. Wenn eine Datei geöffnet wird, wird eine neue Aktivität gestartet, um diese Datei anzuzeigen. Sie können auf die Schaltfläche "Letzte Apps" klicken, mit der Sie zurück zum Browser gehen können, ohne das geöffnete Dokument zu schließen, und vielleicht sogar ein anderes Dokument parallel zu dem ersten öffnen.


Meiner Meinung nach ist es nicht wirklich relevant. Der Schlüsselfaktor ist zu beachten

  1. Wie oft werden Sie Teile der Benutzeroberfläche (Menüs zum Beispiel) wiederverwenden,
  2. ist die App auch für Tablets?

Die Hauptverwendung von Fragmenten besteht darin, Multipane-Aktivitäten zu erstellen, was es ideal für Tablet / Phone-fähige Apps macht.


Vergessen Sie nicht, dass eine Aktivität der Block / die Komponente der Anwendung ist, die durch Intent geteilt und gestartet werden kann! Daher sollte jede Aktivität in Ihrer Anwendung nur eine Art von Aufgabe lösen. Wenn Sie nur eine Aufgabe in Ihrer Anwendung haben, dann brauchen Sie bei Bedarf nur eine Aktivität und viele Fragmente. Natürlich können Sie Fragmente in zukünftigen Aktivitäten wiederverwenden, die andere Aufgaben lösen. Dieser Ansatz wird eine klare und logische Aufgabentrennung sein. Und Sie müssen keine Aktivität mit verschiedenen Intent-Filterparametern für verschiedene Sätze von Fragmenten pflegen. Sie definieren Aufgaben in der Entwurfsphase des Entwicklungsprozesses basierend auf den Anforderungen.


Nun, nach Googles Vorträgen (vielleicht erinnere ich mich nicht daran) sollten Sie, wann immer es möglich ist, die Verwendung von Fragmenten erwägen, da dies die Wartung und Kontrolle Ihres Codes erleichtert.

Ich denke jedoch, dass es in einigen Fällen zu komplex werden kann, da die Aktivität, die die Fragmente hostet, zwischen ihnen navigieren / kommunizieren muss.

Ich denke, du solltest selbst entscheiden, was das Beste für dich ist. Es ist normalerweise nicht so schwer, eine Aktivität in ein Fragment umzuwandeln und umgekehrt.

Ich habe hier einen Beitrag über dieses Dilemma erstellt, wenn Sie weiterlesen möchten.


Sie können eines davon verwenden.
Grundsätzlich müssen Sie bewerten, welche die beste für Ihre App ist. Denken Sie darüber nach, wie Sie den Geschäftsablauf verwalten und wie Sie Datenvoreinstellungen speichern / verwalten.

Denken Sie darüber nach, wie Fragmente Daten zum Müll speichern. Wenn Sie das Fragment implementieren, haben Sie einen Aktivitätsstamm, der mit Fragmenten gefüllt wird. Also, wenn Sie versuchen, viele Aktivitäten mit zu vielen Fragmenten zu implementieren, müssen Sie die Leistung in Ihrer App berücksichtigen, denn Sie manipulieren (grob gesprochen) zwei Kontextlebenszyklen, denken Sie an die Komplexität.

Denken Sie daran: Soll ich Fragmente verwenden? Warum sollte ich nicht?

Grüße.


Verwenden Sie eine Aktivität pro Anwendung, um Basis für fragment Nutzung fragment für Bildschirm, fragments sind Lite Gewicht im Vergleich zu activites Fragmente sind wiederverwendbare Fragmente sind besser geeignet für App, die sowohl Telefon und Tablet unterstützen


Eine andere hier gepostete Lösung setze setPrimaryItem im pageraster von kris larson fast für mich. Diese Methode wird jedoch mehrmals für jede Konfiguration aufgerufen. Auch habe ich NPE aus Ansichten usw. im Fragment, da dies nicht die ersten paar Male bereit ist, die diese Methode aufgerufen wird. Mit den folgenden Änderungen funktionierte das für mich:

private int mCurrentPosition = -1;

@Override
public void setPrimaryItem(ViewGroup container, int position, Object object) {
    super.setPrimaryItem(container, position, object);

    if (position == mCurrentPosition) {
        return;
    }

    if (object instanceof MyWhizBangFragment) {
        MyWhizBangFragment fragment = (MyWhizBangFragment) object;

        if (fragment.isResumed()) {
            mCurrentPosition = position;
            fragment.doTheThingYouNeedToDoOnBecomingVisible();
        }
    }
}




android android-fragments android-activity architecture