На всякий случай уточню, что это старый репозиторий старой версии мокси. Новый в шапке

1) конкретно в этом случае наверное чтобы не триггернуть cancel listener при вызове dismiss

2) по идее ни на что

3) нет, чтобы при обычном сворачивании экрана не убирать диалог

аа, точно. Спасибо

на практике тоже, просто уточнить хотел)

Это скорее всего следы древних практик, когда super.onPause и прочее вызывали в конце)

это уже не обязательно? 🙄

я обычно всегда делаю super в начале метода, где-то читал про это пост, но пока найти не могу. Иногда бывают случаи, когда нужно что-то пропихнуть перед, например super.onCreate, DI инициализировать, например, но это всегда по какой-то конкретной причине, а не как best practice.

можно еще в init DI инжектить, чтобы отделить как-то код. Слышал, что это норм практика вроде.

Это уже зависит от того, как у вас конкретно DI сделан.

ну и в гайдах официальных уже всегда в начале пишут)

Всем привет!

Только недавно начал пытаться работать с андроидом и мокси и уже который раз сталкиваюсь с проблемой:
Если ты пишешь какую-нибудь достаточно сложную логику, ты неизбежно упираешься в ограничения концепциии один view -  один presenter.
Если тебе просто нужно протащить некоторую совокупность данных через какую-то череду форм и страниц, ты можешь сделать один пресентер на кучу фрагментов и поместить его в некоторый общий родительский фрагмент/активити.
Но бывают ситуации, например, когда один и тот же фрагмент должен фигурировать в разных частях программы, и всякий раз получать какие-то данные от вызвавшей вьюхи и тогда я сталкиваюсь с целой плеядой возможных решений, оно страннее другого.
1) Передавать данные между пресентерами через вьюху, но это сущий ад, который загромождает и уродует код.
2) Скажем вьюхи А и Б, могут вызывать С. Можно сделать некоторый абстрактный презентер для С и унаследовать от него А и Б, и тогда данные остануться инкапсулированны, но усложнится структура классов.
3) Я ещё не пробовал, но может можно как-нибудь красиво агрегировать пресентеры между собой минуя слой представления?

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

Думаю, стоит рассмотреть синхронизацию данных через domain, который мониторит базу.
Идея такая: UI подписывается на базу (room умеет генерить Flow/Observable для запроса), и получает обновления при любых изменениях базы. База может апдейтиться откуда угодно и после апдейта UI автоматически получает новые данные.
На начальном этапе можно не прикручивать базу, а просто через subject сделать.

В целом, идея такая: передавать данные не через view слой, а через domain

Похоже, это действительно решает более менее все мои проблемы
Спасибо!

Добрый вечер, столкнулся с такой проблемой:

Как я понял, это из-за того, что функции принимают Enum в качестве параметров

смените имя одного из методов. они у вас названы одинаково и принимают параметром Enum<T>

Ничего не поменялось