Android a MVP

0

Witam!
Mam kilka pytań które mnie dręczą w architekturze MVP, którą zastosowałem w mojej aplikacji.

  1. Mam Activity o nazwie UserSearchActivity, w niej jest po prostu SearchView z RecyclerView, mają za zadanie używając Rest API Githuba wyszukiwać po nazwie użytkowników, jeżeli klikniemy w jakiegoś użytkownika powinno się otworzyć UserDetailsFragment, ale nie jestem pewien jak to rozwiązać. Z tego co wiem przy tej architekturze mam dużą dowolność czy powinienem traktować to jako jeden Widok? Czy jakoś współdzielić obiekt Modelu w którym będzie zapisany kliknięty użytkownik, pomiędzy prezenterami, rozdzielając widok (I wstrzyknąć to np. Daggerem do drugiego prezentera)? Lub po prostu używać paru fragmentów.

Tutaj jak wygląda mój Kontrakt:

interface UserSearchContract {

    interface View {

        fun showDetails(user : User)

        fun showUserList(userList : List<User>)

        fun showLoading()

        fun hideLoading()

        fun notifyUserListChanged()

        fun openUrl(url : String)

    }

    interface Presenter {

        fun onUserClick(user : User)

        fun onRepoClick(repo : Repo)

        fun onQueryEntered(query : String)

        fun onLoadMore()

    }

}
  1. Wiem że Prezenter i Model powinny być niezależne od platformy, powiedzmy że np. Użytkownik posiada bardzo wolne łączę z internetem i żeby to zoptymalizować nie będę ściągał ikon użytkowników i używał takich samych dla wszystkich, lub np. bateria będzie słaba, prezenter powinien o czymś takim widzieć czy widok powinien sam reagować na takie sytuacje?
1
  1. Ja bym to rozwiązał w ten sposób, że po kliknięciu w użytkownika do fragmentu jest on przekazywany (lub jego ID) i potem we fragmencie z detalami użytkownika jest wstrzykiwany prezenter, który jest w stanie pobierać detale tego konkretnego użytkownika. Czyli drugi prezenter przyjmowałby w konstruktorze to ID i działał tylko na nim. Przy okazji nie korzystaj z interfejsów dla prezentera. W większości przypadków świadczy to tylko o niezrozumieniu MVP.

  2. Widok nie powinien mieć bezpośredniego dostępu do takich rzeczy jak stan łącza czy stan baterii. Zależnie od sytuacji powinien dostawać te informacje z zewnątrz i reagować za pomocą metod, albo nie być w ogóle tego świadom i cała odpowiedzialność powinna być w osobnych klasach. Przykładowo jakiś ImageDownloader, który mógłby dynamicznie dostosowywać jakość wyświetlanych zdjęć na podstawie parametrów z zewnątrz.

Był podobny temat już wcześniej na forum. Możesz poczytać - Architektura MVP z Interactorem i Repository.

2

To co napisał kolega z góry. Dodatkowo:

  1. Chciałbym dodać pod analizę zmianę: zastąpienie z interface Presenter parametrów User na uuid: String. Z doświadczenia wiem że najwygodniej przesyłać tam UUID / ID. Dzięki temu jeszcze bardziej odseparowujemy logikę z widoku.
  2. Kolejnym krokiem pod analizę byłoby pewnie zastąpienie w View parametrów User na UserViewModel. Co ta zmiana oznacza? Do widoku będziemy przesyłać gotowe modele do wyświetlenia - tzn model taki to jest "ValueObject" - 1:1 będzie wyświetlony na widoku.
1

Proponuję olać MVP i skupić się na MVVM które dostało dobre wsparcie od Googla i rozwiązuje bardzo dużo problemów :)
tutaj różne sample
https://github.com/googlesamples/android-architecture-components

0

@Michał Sikora: @lubie_programowac Dziękuje za rozjaśnienie sprawy, w tym podlinkowanym temacie było bardzo dużo informacji!
@wojciechmaciejewski Co do MVVM już mam 2-3 apki napisane z użyciem MVVM i po prostu testuje sobie co mi najbardziej odpowiada, według mnie w takich prostych aplikacjach MVVM jest lekkim przerostem treści nad formą.

1 użytkowników online, w tym zalogowanych: 0, gości: 1