Mehrere Aktivitäten/Fragmente und die Modellansicht Presenter-Muster

Question

Erstens, ich weiß, dass es mit Model View Presenter verschiedene Implementierungen gibt, und meiner Meinung nach, solange Sie die Ebenen der Abstraktion klar definiert haben und dann ihre Rollen übernehmen Implementieren Sie dieses Muster ist offen für die Interpretation. Ich habe dieses Muster in vielen Apps implementiert, wo es nur eine Activity gab. Ich habe jetzt ein neues Projekt gestartet, das mehrere Aktivitäten hat und angefügt Fragments, einschließlich verschachtelte Fragmente (ViewPager).

Ich versuche jetzt, den MVP zu diesem Projekt zu übersetzen, und ich habe eine Konzeptwand getroffen und möchte einige Anleitung und Einblicke.

Bisher habe ich die obige Struktur erstellt und begonnen, eine 1: 1-Beziehung mit View & Presenter (unabhängig von Activity oder Fragment) zu tun. Ich fühle, dass dies in Ordnung ist, wenn ich zum Beispiel eine Anfrage von einem Activity View an seinen Presenter gesendet habe, der ein Ergebnis an die Activity zurückgibt. Wie würde ich das Propagieren des Ergebnisses durchführen, dh alle anderen Aktivitäten/Fragmente aktualisieren das sind derzeit nicht in einem Paused() oder Stop() Zustand. Ich denke, in diesem Fall sollte es einen zentralen Moderator geben, der alle notwendigen Aktivitäts- und Fragmentansichten aktualisiert, aber ich bin mir nicht sicher, wie ich das machen soll.

Zeit, wenn jeder Activity und Fragment erstellt es eine neue Instanz eines Presenter-Klasse erstellt, als Referenz an sich vorbei (die Aktivitäten und Fragmente implementieren ihre eigenen Schnittstellen), die den Moderator speichert als WeakReference und kann die aufrufen relevante Schnittstellenmethoden beim Zurückgeben eines Ergebnisses.

Laut der Dokumentation wann immer Fragments miteinander kommunizieren möchten und die beigefügten Activity sollten Sie eine Callback-Schnittstelle verwenden. In diesem Sinne sollte ich eine Callback-Schnittstelle haben, die die Aktivität implementiert und die Fragments Callback zu, wann immer sie etwas anfordern, so dass im Wesentlichen nur die Aktivität einen Presenter und Model-Layer haben würde, die die Fragmente zurückrufen müssen, um verschiedene Anfragen zu machen ?

Tut mir leid, wenn das ein wenig durcheinander klingt, hoffentlich ist das klar genug, um zu verstehen, was ich erreichen will, und wenn ich in die richtige Richtung denke ... oder völlig daneben!

Answer 1

Ich denke, das ist in Ordnung, einen Moderator in Aktivität zu haben. Grundsätzlich ist Aktivität wie ein Controller, sie sollte über den Moderator wissen.

Es wäre falsch, einen Moderator in ein Fragment einzufügen, wenn es auch für eine Aktivität oder ein anderes Fragment benötigt wird. Sie können einen Moderator nur dann in ein Fragment einfügen, wenn dieser Moderator speziell für Fragmente entworfen wurde.

die die Moderatorin speichert als WeakReference und können die entsprechenden Interface-Methoden aufrufen, wenn ein Ergebnis

Rückkehr Warum Sie eine WeakReference hier brauchen? Wenn Sie eine 1: 1-Beziehung haben, nehme ich an, dass Ihr Präsentator keinen eigenen Lebenszyklus hat, was bedeutet, dass der Lebenszyklus von einer Aktivität oder einem Fragment abhängt. Es besteht kein Risiko, Speicherlecks zu haben, weil es kein Singleton ist, oder? Es sollte sicher sein, eine starke Referenz zu haben.

Ich bin mir nicht sicher, ob ich deine Frage beantwortet habe, weil sie mir ein bisschen weit erscheint. Mein Punkt ist, dass Fragmente nur getrennte "Teile" der Aktivität sind und Sie sollten sie als Teile behandeln. Wenn der Moderator nur zu diesem Teil gehört, sollte er innen sein. Ansonsten sollte es in Aktivität sein.Sie haben recht, wenn Sie eine interface verwenden, um auf Aktivitäten zuzugreifen. Dies ist ein bekannter Designansatz, den Google in seinen Beispielen verwendet.

Answer 2

Nein, keine Schnittstelle mehr. Sie verwenden entweder RxJava Observables, um alle Ansichten zu aktualisieren, wie beschrieben here oder eine Art Bus (Otto -vertreten oder EventBus). Und Sie werden es mögen, weil sie die Interaktion zu einfach machen.