презентеры живут вечно?
У меня используется в роли бд реалм, который желательно закрыть когда он больше не нужен или когда закрыли приложение.
Как вы отлавливаете онДестрой приложения что бы позакрывать все конекшены и в какой сущности?

У реалма инстансы нужно открывать и закрывать, привязываясь к жизненному циклу активти. В onCreate открыл, в onDestroy закрыл. Соотвественно также нужно поступать когда он в презентере. Даже если презентер преживает жизненный цикл активити, можно вызывать методы bindView и unBindView и в них закрывать.

Кстати с чатика Мокси прозвучал хороший вопрос, а где должна быть геолокация? Собственно а где должны быть также и ContactProvide, CallendarProvider и прочие андроидовские средства.
Я думаю, что работы с ними должна проводиться в Data слое на уровне работы с той же сетью или БД, то есть под Репозиторием.
Этим мы добиваемся того, что в бизнес-логике не будет андроидовских классов. Ну и плюс получается вполне корректное разделение по слоям.
Кто что думает?

презентеры живут вечно?
У меня используется в роли бд реалм, который желательно закрыть когда он больше не нужен или когда закрыли приложение.
Как вы отлавливаете онДестрой приложения что бы позакрывать все конекшены и в какой сущности?

в нормальных приложениях презентеры живут не вечно, а пока нужна вьюшка. Тоесть когда вьюшка умирает/пересоздается из-за тех же поворотов экрана, то презентер это переживает. Но когда вьюшка убивается окончательно, то и презентер умирает тоже.

в нормальных приложениях презентеры живут не вечно, а пока нужна вьюшка. Тоесть когда вьюшка умирает/пересоздается из-за тех же поворотов экрана, то презентер это переживает. Но когда вьюшка убивается окончательно, то и презентер умирает тоже.

То есть в классе репозитория будут объекты для работы с бд/сеть/геолокация/контакты? ввиде полей класса?

Тут есть и другой подход что презентер и при поворотах умирает, но data слой живет в синглтоне.
к примеру как в этйо статье
https://medium.com/@theMikhail/presenters-are-not-for-persisting-f537a2cc7962#.bylawfdv4

пересоздается из-за тех же поворотов экрана, то презентер это переживает. Но когда вьюшка убивается окончательно, то и презентер умирает тоже.

так а как отличить что фрагмент убился и будет пересоздан от того что он убился окончательно?

как минимум методы isFinishing()/isRemoving() можно дернуть. Те же Mosby/Moxy это решают. Можно у них в искодниках посмотреть.

@eugene_matsyuk Привет. Такой вопросик еще.
Ты говорил, что репозитории не должны знать друг о друге, а если объекты взаимосвязанны, то как при каком-либо действии над одним сохранить данные еще о другом? инжектить DAO или API в репозиторий?

Забота репозитория - отправить запрос для создания комнаты. А то, что для этой комнаты потом должны быть получены какие-то события - это уже бизнес логика. Так почему же не интеракторы этим заниматься должны?