Moderator/View/Viewstate relationshipts

Question

Zum Beispiel ich EditProjectFragment haben, die wenige Elemente enthält:

• TextView (Projektname)
• ColorPicker (Projekt Farbe)
• Spinner (Projekttyp)

Lassen Sie uns sehen:

1. Projektname wird von TextView selbst wiederhergestellt
2. Wer muss Projektfarbe speichern?
3. Wer muss Spinner Wert speichern?

Es scheint ViewState 's Verantwortung. Wenn der Benutzer beispielsweise eine Farbe auswählt, ruft Viewpresenter.onProjectColorPicked(color) auf. Dann ruft Presenterview.setProjectColor(color). Oder View sollte ViewState direkt aktualisieren, ohne Presenter zu rufen, wenn es nicht benötigt?

---

Ein anderes Beispiel. Der Benutzer fügt ein Foto in EditNoteFragment hinzu. Benutzer wählt Foto (presenter.pickPhoto()) ->presenter.addPhoto(photo) genannt und notify View, um Foto zu ViewState & hinzuzufügen, zeigen Sie es. Sollte View Update Note Objekt selbst sein? Sollte es von Presenter gemacht werden? Im ersten Fall bedeutet das, dass ViewState Methoden wie getNote()/setNote(note) zur Verfügung stellt, die von View verwendet werden. Sollte ich Note-Reference durch Update in View.setNote(note) Methode duplizieren? Der zweite Fall bedeutet, dass ich wahrscheinlich Note Objekt in Presenter speichern und nur View aktualisieren sollte, ohne Note darin zu übergeben. Aber es sieht wie ein falscher Weg aus.

---

Mit anderen Worten: was View ohne Presenter ‚s Hilfe tun muss (ein Foto Note Objekt hinzufügen?) Und was die Dinge mit ihm (Mausklicks usw.)?

Answer 1

Viewstate sollte verwendet werden, um verschiedene Zustände Ihrer Ansicht darzustellen. Die Ansicht zeigt eine Ladeanzeige an. wir können also sagen, dass sich die Ansicht im "Ladezustand" befindet. Wann immer sich der "Zustand" ändert, ist normalerweise ein Moderator beteiligt, weil es die Verantwortung des Moderators ist, die Ansichten zu koordinieren. Die Frage ist: Wie definierst du den Staat? Es gibt keine Silberkugel.

Ich glaube nicht, dass es Sinn macht, solch ein Ping-Pong-Spiel wie

1. presenter.onProjectColorPicked(color)
2. view.setProjectColor(color)

es sei denn, zu spielen, Sie sagen, dass es auf das Modell geht (Geschäftslogik) wie folgt:

1. Aufrufe anzeigen presenter.onProjectColorPicked(color)
2. Moderator ruft model.setColor(color)
3. Modell informiert Moderator (über Beobachter-Muster), dass das Modell
4. Presenter ruft view.setData(newModelWithChangedColor) enthält die neue Farbe

Im Allgemeinen geändert wurde: die Sicht gerade angezeigt wird (via Moderator) Was ist der aktuelle Stand des "Modells"?

ViewState ist nur ein kleiner Helfer, der sich mit Änderungen der Bildschirmausrichtung und dem Tod auf eine etwas bequemere Art und Weise befasst (im Vergleich zu herkömmlichen onSaveInstanceState(Bundle) Implementierungen).

Fragen Sie sich also: Wie ist der Zustand Ihres "Modells"? Normalerweise ist der Zustand der Ansicht derselbe wie der Zustand des "Modells".

Im ersten Beispiel scheint es, dass es ein Problem von Farbauswahl und Spinner ist, die ausgewählten Sachen nicht intern zu speichern. Daher ist es die Standardmethode, die das Android-Team empfiehlt, dies manuell in onSaveInstanceState() für den Picker/Spinner zu tun. Also, wenn Sie nur die ViewState Funktion verwenden möchten, um onSaveInstanceState() nicht zu verwenden, weil Sie es bequemer finden, ViewState zu verwenden, dann ist das auch in Ordnung, obwohl es nicht genau das ist, für das ViewState gedacht war.