Android, MVP, czy to dobry przykład?

Postanowiłem ostatnio ogarnąć jakiś wzorzec (w aplikacji android którą piszę zaczęło mi powstawać God-Activity) i wybrałem MVP.
Poszukałem trochę i w kilku tematach na stacku przewinął mi się link https://github.com/googlesamples/android-architecture/tree/todo-mvp/ jako dobry i łatwy przykład do nauki ( w tym samym czasie próbuję to zaimplementować do swojej aplikajcji).
Siedzę nad tym od trzech dni i mam ciągle wrażenie, że, nawet nie wiem jak to do końca określić, czy czasem ten przykład nie jest zwyczajnie przekombinowany (?) i jest tam takie pisanie dla samego pisania? Aplikacja z Git to zwykła TO-DO app, więc coś dosyć prostego, jednak powiem szczerze, że na razie dla mnie jest to zwyczajny chaos (trzy dni to mało czasu i kilka rzeczy już ogarnąłem, ale jest tam mnóstwo skakania pomiędzy różnymi częściami kodu które wydaje się niepotrzebne).
Pytanie do osób zajmujących się Androidem: nadaje się to waszym zdaniem jako dobry, praktyczny przykład implementacji MVP czy może poszukać czegoś innego (najlepiej ściągnąć i samemu zobaczyć)?

MVP jest tylko narzędziem wykorzystanym do faktycznego celu jakim jest odseparowanie warstw w aplikacji. Swoją drogą to można się bawić w MVVM na Androidzie. Cóż, ten przykład jest niezły, ma swoją własną konwencję która mi osobiście nie leży. Aczkolwiek nie widzę w nim jakiś wielkich uchybień. Nawet chyba te Sample były omawiane na jednej konferencji na które byłem. Jak dobrze pamiętam to tylko ogólny koncept i nie należy go brać za pewnik.

Ja się uczyłem MVP poprzez przeczytanie teorii i zaimplementowanie jej w prostej aplikacji. Samo MVP jest banalne, to tylko koncept, klucz do rozwiązania większego problemu jakim jest stworzenie czystej, rozszerzalnej a przede wszystkim testowalnej architektury aplikacji która jest niezależna od frameworka Androida.

Tak jak zrobił MrHyperion, przeczytaj jakiś prosty artykuł na ten temat i samemu to zaimplementuj, choćby z tego linka, tutaj jeszcze krótkie i sensowne porównanie MVC, MVP i MVVM

Przykład całkiem OK aczkolwiek kilka rzeczy mi się nie podoba:

• interfejs dla presentera to overkill
• zależności od frameworka w niektórych presenterach (pewnie stąd wynika pkt. poprzedni ;) )
• metoda start() (?) w presenterze, zwykle unikam wiązania presentera z jakimikolwiek metodami cyklu życia komponentów androida, poza tym nazwa tej metody niewiele mówi

Generalnie MVP w Androidzie sprawdza się dobrze i kodzi się wtedy przyjemnie, zwłaszcza w połączeniu z clean architecture i sensownym dostarczaniem zależności (Dagger anyone?). Problemy są, jak zwykle zresztą z obrotem ekranu (ubić presenter, przetrzymać a jak tak to gdzie żeby nic wyciekło itp itd) czy też cachowaniem danych. Próbowałem już kilkunastu sposobów i żaden mnie nie satysfakcjonuje :)

Oczywiście w trywialnych aplikacjach MVP w takim wydaniu to jest overkill - to samo można osiągnąć programując obiektowo trzymając się zasad SOLID (nie tak jak pokazują w tutorialach ;))

Ogarnąłem na tyle, żeby implementować do swojej aplikacji z bazą danych. Ogólnie mówiąc, królicza nora tego przykładu sięga bardzo głęboko i trzeba sporej gimnastyki umysłowej (przynajmniej dla mnie), żeby się przyzwyczaić.
Co do start() w presenter, to po prostu strasznie poronioną nazwę dali, ponieważ nie łączy się to w żaden sposób z cyklem życia aktywności/fragmentu i jest odpowiedzialne za rozpoczęcie wczytywania danych z bazy (mniej więcej).
Najbardziej wkurzające są miejsca gdy jest skakanie pomiędzy obiektami view<->presenter<->model, gdzie wszystko rozszerza jakiś interfejs i są implementowane jako obiekt interfejs, i ścieżka wykonywanych instrukcji może wyglądać: metoda z view -> metoda z presentera -> metoda z view -> znowu presenter-> model/baza danych i jego klasa bazowa (następny interfejs)-> baza danych właściwa (np. lokalna). I wszystko załatwiane jest callbackiem:).

I pytanie jeszcze: na czym polega overkill w zastosowaniu interfejsu w prezenterze? Nie jest to normalnie, żeby implementować interfejsy zarówno w presenter i w view?

Żeby pozbyć się callback hell można dorzucić RxJava (jestem fanboyem!). Podaj powody dla których potrzebujesz posiadać presenter jako intefejs (wykluczmy przypadek, że potrzeba więcej niż jedną implementację dla danego widoku).

Dlaczego interfejs w presenter? Nie mam pojęcia :). We wszystkich miejscach/przykładach implementacji MVP na które trafiłem, tak do tego podchodzono.
Jestem na etapie nauki tego i przeróbki aplikacji z której kodem (i może z kilku innych) mam zamiar szukać roboty.
Niecały tydzień temu obroniłem się, całkowicie inna działka techniczna której nie mam zamiaru już kontynuować, ale szkoda byłoby zmarnować czas i odpuścić dyplom, i w końcu nic już mnie nie wstrzymuje od pójścia w IT.

@GregoryI: warto wiedzieć co się robi ;) W kilku implementacjach MVP na przestrzeni lat nie spotkałem się jeszcze z sensownym stosowaniem interfejsów dla prezenterów.

@MrHyperion: jedyne sensowne metody cyklu życia dla prezentera to IMO coś w rodzaju create() i destroy(), ewentualnie samo attachView() i detachView(), i żadnego pobierania danych w nich (jak w tym nieszczęsnym start()). Tworząc aplikację androidową staram się jak najbardziej odciąć od frameworka tam gdzie jest jakakolwiek logika, na tyle daleko że mógłbym wymienić 'front' na desktopa beż większego bólu ;) Z RxJavą może wyraziłem się źle - nie znaczy żeby pchać ją gdzie tylko popadnie, ale sensowne wykorzystanie reaktywnego programowania ułatwia sporo rzeczy na Androidzie.

bolson napisał(a):

@GregoryI: warto wiedzieć co się robi ;) W kilku implementacjach MVP na przestrzeni lat nie spotkałem się jeszcze z sensownym stosowaniem interfejsów dla prezenterów.

@MrHyperion: jedyne sensowne metody cyklu życia dla prezentera to IMO coś w rodzaju create() i destroy(), ewentualnie samo attachView() i detachView(), i żadnego pobierania danych w nich (jak w tym nieszczęsnym start()). Tworząc aplikację androidową staram się jak najbardziej odciąć od frameworka tam gdzie jest jakakolwiek logika, na tyle daleko że mógłbym wymienić 'front' na desktopa beż większego bólu ;) Z RxJavą może wyraziłem się źle - nie znaczy żeby pchać ją gdzie tylko popadnie, ale sensowne wykorzystanie reaktywnego programowania ułatwia sporo rzeczy na Androidzie.

Parafrazujesz to co ja napisałem xD, odnośnie cyklu życia :P.