Android, MVP, czy to dobry przykład?

0

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ć)?

0

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.

1

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

0

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 ;))

0

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?

0

Ż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).

0

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.

0

@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.

0
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.

0
MrHyperion napisał(a):
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.

Oj tam, uściślam :D

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