Erstens weiß ich, dass es bei Model View Presenter verschiedene Implementierungen gibt, und meiner Meinung nach, solange Sie die Schichten der Abstraktion klar definiert und ihre festgelegten Rollen erfüllen, ist die Interpretation dieses Musters offen für Interpretationen. Ich habe dieses Muster in vielen Apps implementiert, wo es nur ein Activity gab. Ich habe jetzt ein neues Projekt gestartet, das mehrere Aktivitäten hat und Fragments angehängt hat, einschließlich verschachtelter Fragmente ( ViewPager ).
Ich versuche jetzt, den MVP in dieses Projekt zu übersetzen, und ich habe eine Konzeptwand getroffen und möchte etwas Anleitung und Einblicke.
Bisher habe ich die obige Struktur erstellt und begonnen, eine 1: 1-Beziehung mit View & amp; Moderator (unabhängig von Activity oder Fragment ). Ich denke, dass dies in Ordnung ist, wenn ich zum Beispiel eine Anfrage von einem Activity View an seinen Presenter gesendet habe, der ein Ergebnis an das Activity View zurücksendet, wie würde ich das Ergebnis weiterleiten, dh alle aktualisieren andere Aktivitäten / Fragmente, die sich derzeit nicht in Paused() oder Stop() befinden. 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.
Momentan, wenn jedes Activity und Fragment erstellt wird, erstellt es eine neue Instanz einer Presenter-Klasse und übergibt sich selbst als Referenz (die Aktivitäten und Fragmente implementieren ihre eigenen Schnittstellen), die der Präsentator als% co_de speichert % und kann die relevanten Schnittstellenmethoden beim Zurückgeben eines Ergebnisses aufrufen.
Gemäß den Dokumenten, wenn WeakReference miteinander kommunizieren wollen und die angehängte Fragments , sollten Sie eine Callback-Schnittstelle verwenden. In diesem Sinne sollte ich eine Callback-Schnittstelle haben, die die Aktivität implementiert und den Activity -Rückruf, wenn sie etwas anfordern, so dass im Wesentlichen nur die Aktivität einen Presenter- und Model-Layer haben würde, zu dem die Fragmente zurückrufen müssen verschiedene Anfragen?
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 der richtigen Richtung denke ... oder völlig daneben!
Ich denke, es ist in Ordnung, einen Moderator in der 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 dies auch für eine Aktivität oder ein anderes Fragment erforderlich ist. Sie können einen Moderator nur dann in ein Fragment einfügen, wenn dieser Präsentator speziell für Fragmente entworfen wurde.
, die der Präsentator als WeakReference speichert und beim Zurückgeben eines Ergebnisses die relevanten Schnittstellenmethoden aufrufen kann
Warum brauchst du hier ein WeakReference ? 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 etwas 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 interface für den Zugriff auf Aktivitäten verwenden. Dies ist ein bekannter Designansatz, den Google in seinen Beispielen verwendet.
Tags und Links android mvp android-activity design-patterns android-fragments