8

Po pierwsze, wiem, że z Prezenterem widoku modelu istnieją różne implementacje, i w moim umyśle, o ile jasno zdefiniowano warstwy abstrakcji i ich wyznaczone role, to w jaki sposób wdrożenie tego wzoru jest otwarte na interpretację. Wdrażałem ten wzorzec w kilku aplikacjach, w których był tylko jeden Activity. Teraz rozpocząłem nowy projekt, który ma wiele działań i dołączony Fragments, w tym fragmenty zagnieżdżone (ViewPager).Wiele czynności/fragmentów i wzorzec prezentera Model Viewer

Próbuję teraz przetłumaczyć MVP na ten projekt i uderzyłem w ścianę koncepcyjną.

tej pory stworzyłem powyższej struktury i zaczął robić 1: 1 związek z widokiem & Presenter (niezależnie od Activity lub Fragment). Czuję, że to jest w porządku, ale jeśli na przykład wysłałem prośbę o zrobienie czegoś z widoku Activity View to the Presenter, który zwraca wynik do Activity Zobacz, w jaki sposób chciałbym propagować wynik, tj. Zaktualizować wszystkie inne działania/fragmenty które obecnie nie są w stanie Paused() lub Stop(). Mam wrażenie, że w tym przypadku powinien istnieć centralny prezenter, który aktualizuje wszystkie niezbędne widoki aktywności i fragmentów, ale nie jestem pewien, jak to zrobić.

Obecnie, gdy każdy Activity i Fragment jest tworzony tworzy nową instancję klasy Presenter, przekazując sobie jako punkt odniesienia (działalności i fragmenty realizacji własnych interfejsów), który przechowuje prezentera jako WeakReference i może powoływać się na odpowiednie metody interfejsu podczas zwracania wyniku.

Zgodnie z dokumentami zawsze, gdy Fragments chce się komunikować ze sobą i z dołączonym Activity, należy użyć interfejsu wywołania zwrotnego. Mając to na uwadze, powinienem mieć jeden interfejs wywołania zwrotnego, który implementuje Activity i wywołanie zwrotne od Fragments, gdy tylko o coś poprosi, więc zasadniczo tylko działanie będzie miało warstwę Presenter i Model, do której Fragmenty będą musiały się oddzwaniać w celu wykonania różnych żądań. ?

Przepraszam, jeśli to brzmi trochę pomieszany, mam nadzieję, że jest to wystarczająco jasne, aby zrozumieć, co chcę osiągnąć, i jeśli myślę wzdłuż właściwych linii ... lub zupełnie nie pasuje!

Odpowiedz

1

Myślę, że to jest w porządku mieć prowadzącego w środku aktywności. Zasadniczo aktywność jest jak kontroler, powinien wiedzieć o prezencie.

Niewłaściwe byłoby umieszczenie prezentera wewnątrz fragmentu, jeśli aktywność lub inny fragment też tego potrzebuje. Możesz umieścić prezentera wewnątrz fragmentu tylko wtedy, gdy prezenter został zaprojektowany specjalnie na fragment.

który przechowuje prezentera jako WeakReference i może wywołać odpowiednie metody interfejsu po powrocie wynik

Dlaczego trzeba WeakReference tutaj? Jeśli masz relację 1: 1, zakładam, że Twój prezenter nie ma własnego cyklu życia, co oznacza, że ​​cykl życia zależy od aktywności lub fragmentu. Nie ma ryzyka wycieku pamięci, ponieważ nie jest to singleton, prawda? Powinno być bezpiecznie mieć silne referencje.

Nie jestem pewien, czy odpowiedziałem na twoje pytanie, ponieważ wydaje mi się ono zbyt szerokie. Chodzi mi o to, że fragmenty są po prostu oddzielonymi "częściami" aktywności i powinieneś traktować je jako części. Jeśli prezenter należy tylko do tej części, to powinien być w środku. W przeciwnym razie powinno to być działanie.Masz rację, jeśli chcesz uzyskać dostęp do aktywności za pomocą interface, jest to dobrze znane podejście do projektowania, które Google stosuje w swoich przykładach.

+0

Dziękuję za komentarze i przemyślenia. Myślę, że po prostu użyję Presentera z Działalnością i pozwolę sobie na aktualizację fragmentów. Pamięć przecieka z Singletonem? Stałoby się tak tylko wtedy, gdyby Singleton miał odniesienie do działania lub fragmentu (w zasadzie coś z cyklem życia, który może nadejść i odejść)? Jeśli tak, używam singletonu na coś innego, ale nie ma żadnych odniesień. Używam 'WeakReferences' z Działaniami i Fragmentami (cokolwiek z odwołaniami cyklu życia), ponieważ nie muszę' null' Silne referencje dotyczące zmian konfiguracji, a 'WeakReference' zezwala na GC –

+0

Jeśli twój prezenter nie jest singletonem, to nie powinieneś. • Masz problem ze zmianami konfiguracji, ponieważ sam prezenter również zostanie odtworzony. Możesz potrzebować 'WeakReference' jeśli użyjesz zatrzymanego fragmentu chociaż. W każdym razie wydaje się, że wyraźnie rozumiesz, jak słabe referencje działają, więc nie muszę tego wyjaśniać. Dziękuję. –

+0

Żaden prezenter nie jest singletonem, Po utworzeniu prezentera przechowuję jego odwołanie w 'HashMap ' wewnątrz bezgłowego zatrzymanego fragmentu i odzyskuję jego odniesienie do zmian konfiguracji za pomocą działania. ... Kiedy wydaje mi się, że rozumiem coś na Jawie, wydaje mi się, że zawsze rzucał mi krzywą piłkę! Dzięki za radę. –

1

Nie, już nie ma interfejsu. Możesz użyć RxJava Observables, aby zaktualizować wszystkie widoki zgodnie z opisem here lub pewnego rodzaju Bus (Otto -deprecated lub EventBus). I spodoba ci się, ponieważ zbyt łatwo wchodzą w interakcje.

+1

Dziękuję za twoje komentarze, krótko je obejrzałem - i wyglądam całkiem wykonalnie i interesująco. Szukałem raczej rozwiązania wzorcowego lub koncepcji niż "biblioteka ta zabiera złożoność". Nie jestem przeciwny używaniu tej lub innych bibliotek, które rozwiązują problemy, z dala od tego, ale uważam, że ważne jest dla mnie zrozumienie dobrego zrozumienia przed przejściem do korzystania z tych innych bibliotek, które radzą sobie z wieloma złożonościami. –

+0

İ nazwałbym to podejściem programowania reaktywnego, a nie biblioteką. I nie widzę innego sposobu, aby uciec Rx już w najbliższej przyszłości. –

+0

Na pewno popatrzę na programowanie reaktywne/RxJava, na razie dla mnie i dla tego projektu komunikacja za pośrednictwem hostingu nie jest problemem. Nie jestem pewien, czy podzielam twoje przekonanie, że nie ma sposobu na "ucieczkę" od programowania reaktywnego, jednak szanuję twoją opinię. –