2016-07-13 14 views
10

Im MVP-Muster wer ist verantwortlich für Klicks auf der Benutzeroberfläche zu behandeln?
Zum Beispiel der nicht-MVP Ansatz wäre so etwas wie:In MVP ist OnClick Verantwortung von View oder Presenter?

counterButton.setOnClickListener(new View.OnClickListener() { 
    public void onClick(View v) { 
     totalClicks++; 
     counterTextView.setText("Total clicks so far: "+totalClicks); 
    } 
    }); 

Mit MVP die onClick in der Verantwortung der Presenter ist? Oder die View kann damit umgehen?
Kann jemand bitte dies klären?

Antwort

17

OnClick sollte eine Presenter Methode aufrufen. Sie sollten Ihr Geschäft in Presenter tun und wenn Sie das UI aktualisieren müssen, sollten Sie eine Methode in Ihrem View definieren und es von Presenter aufrufen.

Sie benötigen eine Methode für Ihre View ex:

public void showCounterCount(final int totalClicks){ 
    counterTextView.setText("Total clicks so far: "+totalClicks); 
} 

Darüber hinaus müssen Sie ein Verfahren und eine Variable in Ihrer Presenter:

int totalClicks = 0; 

public void onCounterButtonClicked(){ 
    totalClicks++; 
    mView.showCounterCount(totalClicks); 
} 

Und Refactoring Code wie folgt:

counterButton.setOnClickListener(new View.OnClickListener() { 
    public void onClick(View v) { 
     mPresenter.onCounterButtonClicked(); 
    } 
    }); 

Für komplexere und saubere Architektur können Sie Ihren Anwendungsfall tun Geschäft in Interaktoren. (In Ihrem Beispiel ist das Erhöhen eines Zählerwerts ein Anwendungsfall für Ihre Anwendung.)

Sie können einen Interaktor definieren und dort den Zählerwert erhöhen.

CounterInteractor:

public CounterInteractor{ 
    public int incrementCounter(int currentCounter){ 
     return currentCounter+1; 
    } 
} 

Und Ihr Moderator Refactoring wie unten:

int totalClicks = 0; 
CounterInteractor mCounterInteractor = new CounterInteractor(); 

public void onCounterButtonClicked(){ 
    totalClicks = mCounterInteractor.incrementCounter(totalClicks); 
    mView.showCounterCount(totalClicks); 
} 

Mit diesem Ansatz, den Sie trennen Ihre Geschäftslogik vollständig von Moderatoren und wieder Ihre Use-Case-Konzepte verwenden, ohne Code zu duplizieren in Moderatoren. Dies ist ein sauberer Ansatz.

Sie können diese Git Repo auch für verschiedene MVP-Ansätze überprüfen. https://github.com/googlesamples/android-architecture/tree/todo-mvp-clean/

Viel Glück.

Edit:

Hier ist meine leichte wikipedia-Client-Projekt Quelle: https://github.com/savepopulation/wikilight

Ich versuche MVP zu implementieren. (MVP + Dagger2 + RxJava)

+1

Um ehrlich zu sein, wenn das der MVP-Ansatz ist, sehe ich es nicht wirklich als eine Verbesserung als das Original-Snippet. Wir haben gerade 1 Abstraktion/Umleitung hinzugefügt, aber wo ist der Vorteil? – Jim

+1

teilen wir App auf drei Schichten und separate Geschäftslogik von ui. Aktivitäten und Fragmente sind Ansichten und nur für die Aktualisierung von ui verantwortlich und enthalten nur Schnittstellenmethoden, die vom Moderator aufgerufen werden. Ihr Beispiel ist sehr einfach, daher ist es schwer, die Vorteile zu sehen, aber in großen Apps können Sie es klarer sehen. es ist auch nützlich für das Testen. Sie können diesen Link überprüfen. http://antonioleia.com/mvp-android/ – savepopulation

+4

Ein großer Vorteil ist das Testen.Im obigen Beispiel können Sie einen Unit-Test für die Methode 'onCounterButtonClicked()' im Presenter schreiben, ohne dass eine Abhängigkeit vom Android-Framework besteht. Solche Tests können auf der JVM ausgeführt werden. Nebenbei vermeide ich Wörter wie "button" und "click" in meinen Presenter-Methodennamen, um sie weniger eng mit den Konzepten des View-Layers – Jahnold