Więc skończyłem wdrażanie czegoś, co zalecane przez @ Jahnold. (Zamieszczę diagram w linku podanym na pomysł stackoverflow.com/a/41966497/568898)
Hannes Dorfmann (facet, który stworzył/zarządza słynną biblioteką MVP Mosby: Github link) również wskazał mi w tym kierunku.
Wykonanie
mam prezenterem głównego działania i wiele fragmentów, które mogą być wykorzystywane w tej czynności. Każdy fragment ma swojego własnego prezentera. Następnie używam repozytorium (wyszukaj wzór repozytorium), który zasadniczo przechowuje modele i logikę biznesową. Dla mojego przypadku użycia, przechowuję to repozytorium jako singleton. Repozytorium udostępnia dane w trzech formach: z api online, bazy danych sqllite lub pamięci podręcznej przechowywanej w pamięci (w zasadzie lista elementów). Mam również niektóre indeksy int currentitem i rzeczy w tym repozytorium, które są aktualizowane na podstawie bieżącego stanu.
W związku z tym dane, stan i logika biznesowa są przechowywane w tym udostępnionym repozytorium. Prezenterzy i widoki są dość głupie. Nie mam dużej logiki biznesowej (logika specyficzna dla aplikacji) w prezenterach. Mają po prostu logikę związaną z tym, jak dane mają być wyświetlane (zobacz konkretną logikę) i preprocessing w logice je.
Przykład
Ilekroć fragment i działalność muszą ze sobą rozmawiać (przez prezenterów), gdy użytkownik kliknie przycisk we fragmencie dziecięcej, fragment prosi swojego prezentera do handleClick, prezenterzy aktualizuje repozytorium currentItemSelected dane (lub coś innego) i prosi fragment, aby wystrzelił zdarzenie (np. onbuttonclick) do odbiornika, który implementuje aktywność. Gdy aktywność otrzyma zdarzenie, prosi o to swojego prezentera, który z kolei będzie szukał aktualizacji w repozytorium, aby pobrać nowy currentItemSelected.
Extra Info (wersja zaawansowana):
Można również śledzić Clean architekturę, która jest jakby bardziej zaawansowanej wersji MVP architektury. MVP po prostu zajmuje się architekturą widoków, gdzie jako czysta architektura zajmuje się również logiką biznesową i architekturą danych, MVP to tylko niewielka część czystego łuku, która służy do obsługi widoków. Dzięki temu możesz podzielić mega repo w moim przypadku na kolejne przypadki użycia (lub interakcje), które obsługują konkretny przypadek użycia logiki biznesowej, a repozytorium właśnie dostarcza dane. Zatem przepływ logiki jest teraz widokiem -> prezenter -> interaktor -> repo iz powrotem.
Utrzymuj dane za pośrednictwem modelu. To nie jest dokładnie to samo, ale zobacz diagram dodany w tej odpowiedzi - http://stackoverflow.com/a/41966497/568898. Trwałość może być tak prosta, jak zmienna statyczna (ale tego nie zalecam). – Jahnold
@Jahnold Ok, więc zaimplementowałem repozytorium/interaktora, który jest wspólny dla obu prezenterów (czy jest to singleton)? W tym przypadku powiedzmy, że działanie tworzy nowy obiekt interaktora i przekazuje go do nadrzędnego prezentera za pośrednictwem konstruktora. tj. w działaniu: 'onCreate() { mInteractor = new UserInteractor; mPresenter = new Presenter (this, mnternter); } // i fragmentu: onCreateView() { mFragmentType1Presenter = nowy FragmentType1Presenter (. To getActivity() mInteractor); } ' Czy jest to zgodne z zasadą MVP i nie powoduje żadnych problemów? Dzięki. – XenoChrist
Nie używaj interaktora z aktywności w swoim fragmencie. To by ich łączyło. Po prostu użyj osobnej instancji (lub jeśli naprawdę masz do singletona) – Jahnold