да, этот тип подключения зависимости как раз так работает. Указанная зависимости участвует в компиляции чтобы она корректно сработала, но в итоговый артефакт не попадает

Спасибо, Алексей.

так вот зачем нужен compileOnly!

Зачем же ещё)

да вот искал практическое применение, нигде не мог найти

Всем привет Ребята! Помогите пожалуйста понять работу МОКСИ.  Создал тестовое приложение с одним активити. В презентере работает функция обратного счетчика и каждую секунду вызывает viewState.getResult(second: Int).

Когда происходит поворот экрана счетчик вызывается повторно и тикают друг за другом

}

Потому что вы дёргаете метод presenter.launchTimer каждый раз когда стартует Activity

Запускайте таймер в методе onFirstViewAttach() в презентере и всё будет отлично.

Спасибо! Сейчас попробуем

у вас на скриншотах оба раза активити
лучше из активити не пробрасывать жизненный цикл в презентер
вы дергаете функцию запуска таймера из функции жизненного цикла активити так лучше не делать
имя функции getResult странное, должно быть setResult
и кажется стратегия выбрана не совсем правильная
ну и вишенка только прошу остальных сильно не реагировать second.toString() - это бизнеслогика
лучшее ее держать в презентере

у меня кстати был вопрос про бизнеслогику. Вот допустим у меня серия коллбеков при удалении чего-то: Окно раз, диалог два, снэкбар три, все поочереди. Я взаимодействую с одной сущностью в них и отображаю какую-то информацию связанную с ней. Надо ли в метод вьюстейт передавать сырые данные или лучше передавать id сущности и во view извлекать из презентера напрямую все что нужно, используя этот id?

иначе непонятно как прогнать эту сущность через все коллбеки правильно

я сейчас запоминаю ее в презентере(как последюнюю, с которой повзаимодействовали) и передаю из нее сырые данные в методы viewstate(то есть не прогоняю через все коллбеки. Даже по id).
Но лучший ли это способ непонятно

надеюсь я правильно понял вопрос
я передаю минимальный набор
если в диалоге надо отобразить текст связанный с удаляемым элементом то он формируется в презентере
презентер потом ловит результат диалога
и лучше чтобы этот результат содержал ID удаляемого элемента
то есть нужна инфа по которой презентер потом поймет:
- какое действие было выполнено
- что пользователь выбрал (согласился, нажал отмену)
- и над каким элементом производилось действие

понял, спасибо

стоит ли считать багом, что метод MvpPresenter#onFirstViewAttach вызывается не только при самом первом присоединении, но и после смерти процесса, делая невозможным выбор стартового экрана, т.к. условие savedInstanceState == null будет упущено и я сброшу прежний прогресс