Wpis z mikrobloga

@DanielAquarius: twoim "Modelem" mógłby być jakiś ParentInteractor, który miałby jakieś tam Subinteraktory w sobie (wzorzec Kompozyt). I tutaj już prosto, Interactor ma w sobie np. FirebaseManagera, z którym gada poprzez interfejs xxxRepository (który zapewne wypuszczałby publiczne metody takie jak put(...), get(...), update(...) etc) i tyle.

Wtedy model komunikacji wygląda tak, że masz FeatureView, on gada z FeaturePresenterem, on z kolei gada z FeatureInteractorem, który deleguje pracę do swoich 'managerów', które są
@sharaquss: Hmm... A gdyby tak stworzyć jakiegoś helpera i kontaktować go z prezenterem przez interfejs?
Pomysł cenię, tylko chcę się w miarę wpasować w jakiś elegancki sposób implementacji tego wzorca żebym potem z tego sensownie korzystał w potencjalnej pracy :)
Chyba trzeba będzie się zainteresować tym Rx i CA.
@DanielAquarius: To akurat nie jest najlepszy pomysł, bo:

1: Jeżeli do flow Twojego ekranu dojdzie gadanie z serwisem (albo kilkoma), konfigurowanie np. paginacji, lub czegoś takiego poprzez preferencje użytkownika, persystencja, analityka, i czego tam jeszcze możesz potrzebować w przyszłości, to zobaczysz jak prezenter błyskawicznie 'spuchnie', bo będzie musiał sam uderzać i obsługiwać callbacki lub strumienie (jeżeli używasz Rx) z miliona Helperów. Presentery po 1000 linii kodu nie są cool ( ͡
@sharaquss: Dzięki za komentarz. Trochę mi rozjaśnia i nakierowuje na inne myślenie, bo większość tych pożal się jezusku tutoriali jest o kant dupy potłuc, bo opierają się na najprostszych przykładach, a nie drążą innych problemów.
Polecam użycie wzorca repozytorium i zastosowanie UseCase'ów.

https://medium.com/corebuild-software/android-repository-pattern-using-rx-room-bac6c65d7385

Idealnie i zgodnie z Clean Architecture Uncle Bob'a polecam większą sepracje.
(https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html)

View głupi widok, Presenter głupi łącznik pomiędzy widokiem (poprze interfejs), a resztą.
Logika bizesowa realizowana w ramach UseCase'ów:
https://stackoverflow.com/questions/48119036/clean-architecture-usecases-and-entities
Idealnie 1 UseCase na 1 zastosowanie biznesowe, np pobierz dane z repozytorium.
Genralnie im mniejsze klasy, mniejsza odpowiedzialnośći, większa sepracja, zawsze lepiej.

Presenter przyjmuje odpowiednie UseCase'y w konstruktorze, UseCasy przyjmują odpowiednie Interfesjy