MVP Android - ilu prezenterów?

Question

Mam krótkie pytanie. Próbuję (i walczę), aby zaprojektować swoją aplikację ze wzorcem projektowym MVP.

Czy mogę zapytać, dla każdego widoku (aktywność, fragment) powinienem mieć oddzielną klasę prezentera?

Nie ma zbyt wielu zasobów, które mogę zobaczyć w Internecie, które z przykładami ilustrują MVP. Czy ktokolwiek mógłby się nimi dzielić, gdyby miał jakieś?

PS Jestem również za pomocą RecyclerViewAdapter w tej aplikacji więc wszelkie wskazówki na temat, który byłby doceniane

góry dzięki

Answer 1

Konstrukcja Model-View-Controller pojawiły się bardzo wcześnie w softwaredesign i pierwotnie była używana do takich rzeczy jako element przycisku. Używasz MVP (w zasadzie tego samego co MVC), aby uzyskać architekturę, która jest modułowa i łatwa w utrzymaniu, dzieląc reprezentację od logiki.

Biorąc pod uwagę twoje pytanie, myślę, że rzeczywiście chcesz jedną klasę na widok. To byłoby najbardziej powszechne podejście.

http://antonioleiva.com/mvp-android/ podaje teoretyczny przegląd MVP.

Answer 2

Chociaż stare, jest to bardzo interesujące pytanie. Odtąd MVP/MVC/MVVM to rodzaj "buzz-words" w społeczności Androida, to pytanie zasługuje na bardziej kompletną odpowiedź (IMHO).

Krótka odpowiedź:

pojedyncze prezenter może być używany z wieloma widokami

odpowiedź Long:

W ogóle nie ma jednej definicji MVP/MVC - istnieją wiele podejść do realizacji tych wzorów architektonicznych. Nie podałeś definicji "twojego" MVP, dlatego mogę tylko zgadywać, co masz na myśli.

To powiedziawszy, istnieją pewne "najlepsze praktyki" w programowaniu obiektowym, które każda implementacja dowolnego wzoru architektonicznego powinna (idealnie) brać pod uwagę.

To, o co pytasz, to czy możesz ponownie wykorzystać jedną implementację prezentera z różnymi widokami, prawda? Spójrzmy na to pytanie przez pryzmat zasad SOLID.

"L" oznacza Liskov Substitution Principle (LSP). Jest to jeden z najbardziej niezrozumiany zasad SOLID, ale ogólna idea tej zasady mówi co następuje:

LSP: jeśli fragment kodu działa z obiektu klasy A, należy również bezproblemową pracę z obiektami dowolnej podklasy (tj podklasy musi być użyteczny zamiast całym świecie)

Przykład LSP naruszenie w Androida jest Context: sublasses z Context (np Application i Activity) nie są równoważne.Niektóre kod wymagające Context mogą bezproblemowo współpracować z Application, ale jeśli przejdziesz przez Activity, nastąpi wyciek pamięci (jest to bardzo rozpowszechniony błąd w aplikacjach systemu Android, który jest spowodowany głównie przez naruszenie LSP przez twórców Google'a).

Powrót do góry pytania. Jestem zakładając, że prezenterka wygląda następująco (zauważ interfejs dla widoków):

public class SomePresenter { 

    /** 
    * Views bound to this presenter must implement this interface 
    */ 
    interface SomeView { 
     void doSomething1(); 
     void doSomething2(); 
    } 

    public void bindView(SomeView someView) { 
     // view binding logic 
    } 

    // more presenter's methods 

} 

LSP stwierdza, że ​​każda klasa, która implementuje SomeView może być użyteczny z SomePresenter. Prezentujący nie powinien przejmować się tym, czy przekazana mu implementacja SomeView to: Activity, Fragment, lub, może, tylko fałszywa do testu jednostkowego.

Tak więc pełna odpowiedź na twoje pytanie brzmi: jeden prezenter może być ponownie użyty z różnymi widokami, o ile prezenter nie zależy od konkretnych implementacji poglądów, ale tylko od ich super-klasy.

Dodatkowe informacje:

Przypuszczam, że poprosił swoją pytanie, ponieważ, z jednej strony, czułeś, że pojedyncza prezenter powinien być w stanie pracować z różnymi widokami (tylko myśleć o testach A/B różnych UI), ale z drugiej strony fakt, że poglądy są Activity i Fragment sprawił, że czujesz się niekomfortowo z tą myślą.

Moja osobista opinia jest taka, że ​​w MVC/MVP nie powinno być widoków Activity ani Fragment. Uzasadnienie tego roszczenia jest podsumowane w tym wpisie: Why Activities in Android are not UI Elements.

Proponuję także, aby przyjrzeć się różnym podejściem do implementation of MVP in Android - jeśli chcesz używać tego jednego, byłoby oczywiste dla Ciebie, że prezenter powinien być w stanie pracować z różnymi widokami, i nie miałbyś takiego odczucia "coś nie jest w porządku".

Answer 3

Twoja aktywność/fragment powinien mieć 1 prezentera. Chciałbym, aby wszystkie moje działania, które rozciągają się od BaseActivity, a następnie, robię to BaseActivity wymaga Presenter, patrz poniższy przykład:

public abstract class BaseActivity<Presenter extends BasePresenter> extends AppCompatActivity { 

    protected Presenter mPresenter; 

    @NonNull 
    protected abstract Presenter createPresenter(@NonNull final Context context); 

    @Override 
    protected void onCreate(final Bundle savedInstanceState) { 
     super.onCreate(savedInstanceState); 
     mPresenter = createPresenter(this); 
     mPresenter.onCreate(savedInstanceState); 
     } 
    } 
    // other lifecycle methods 

a następnie tworzyć abstrakcyjne BasePresenter

public abstract class BasePresenter { 

protected BasePresenter() { 
} 

@NonNull 
public static BasePresenter nullPresenter(@NonNull final Context context) { 
    return new BasePresenter() {}; 
} 

@CallSuper 
public void onCreate(@Nullable final Bundle savedInstanceState) { 
} 

teraz podczas tworzenia aktywności, wykonaj następujące czynności:

public class MyActivity extends BaseActivity<MyActivityPresenter>{ 


@Override 
MyActivityPresenter createPresenter(@NoNull final Context context){ 
    return new MyActivityPresenter(all, Your, Dependencies, Here); 
    } 
} 

teraz oglądać this video i zrozumienia zakresu odpowiedzialności działalności/Widok wi cienki MVP.