MVP в Android e със сложен интерфейс от няколко фрагмента
Опитвам се да овладея разработката за Android и след няколко посещения винаги затъвам в спагети кода от раздути дейности и фрагменти. Затова реших да приложа най-добрите практики по отношение на архитектурата и по-точно MVP. По принцип идеята е красива и всичко се изпълнява доста просто, но възникна основен въпрос.
Да предположим, че имаме приложение с два панела - за конкретност, нека вземем карта с маркери и списък с тези маркери. Съответно има два фрагмента: MyMapFragment и MyListFragment. По принцип избор, добавяне, изтриване, щракване и други събития могат да бъдат уловени от всяко от тях. Задачата е да координираме състоянията на двата дисплея: ако сме избрали маркер на картата, тогава трябва да го изберем в списъка или ако сме променили името на маркера в списъка, тогава трябва незабавно да го актуализираме на картата. Въпрос: кой начин е най-правилният?
Виждам три опции: 1)Всички аспекти на координирането на изгледа са на Presenter.
Съответно, веднага след инстанцирането на Presenter, ние регистрираме всеки фрагмент в него като имплементация на интерфейси за обратни извиквания на MarkersView. В същото време важен момент: Водещият ясно знае коя реализация към какво се отнася и коя реализация се отнася към него. С други думи, в допълнение към функцията за маршрутизиране на данни от изглед към модел и обратно, нашият Presenter вече също маршрутизира известия за събития между известните му изгледи. Но доколкото разбирам, това нарушава идеологията на MVP в смисъл, че водещият вече знае твърде много за възгледите.
2)Presenter се занимава само с маршрутизиране на данни, а преговорите за изглед се обработват от отделен междинен клас MarkersViewsMediator.
В този случай Presenter е сляп и приема събития от всеки от фрагментите иизвиква обратните извиквания на фрагмента, който го е извикал. За да договорят своите състояния, фрагментите използват MarkersViewMediator като обща шина за съобщаване на актуализации на своите състояния. Но тук можете да забележите потенциален проблем - Презентаторът не знае нищо за фрагментите, регистрирани в него (това е добре), така че може или да изтегли обратното извикване на един фрагмент, който го е адресирал (подобно на опцията, когато всеки фрагмент има собствено копие на презентатора), или всички наведнъж (и тук вече могат да възникнат проблеми и лош код).
3)Както в точка 2, но фрагментите комуникират с презентатора само чрез посредник.
С други думи, нашият посредник става главен изглед, координиращ работата на фрагментите, изпращайки събития до презентатора и осигурявайки изпълнение на обратни извиквания. Но размерът на такъв клас може да бъде впечатляващ и като цяло той трябва да е напълно наясно с фрагментите, свързани с него. Може да се отбележи, че дейност, съдържаща същите тези фрагменти, може да бъде подходяща за ролята на такъв посредник. Истината ще трябва да бъде тясно свързана със събитията от неговия жизнен цикъл. Друг вариант е отделен сингълтън.
Или може би има друг по-добър начин?
