последняя кнопка

Помогите, пожалуйста, понять. Плохо разбираюсь в годгене.
Moxy и Cicirone построены по одному шаблону (Command), но при этом в Cicirone нет кодгена, а в Moxy есть. Почему?

потому, что в Cicerone есть ограниченный сет команд, а Моху генерирует на каждый метод вьюшки свою команду с одной из доступных стратегий

благодарю

Привет всем. А как получить контекст в презентере? Как вообще правильнее действовать в такой ситуации (мб есть best practices какие-то)?

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

Передать в конструктор app context можно

нельзя в презентере использовать android типы
делается враппер над контекстом
простая проверка можно или нельзя передавать контекст это unit тест
что вы будете передавать в презентер в качестве контекста в unit тесте?

нужен для инициализации storageHelper'a моего

тогда возникает вопрос как тестировать работу с внутренним хранилищем, если там все завязано на контексте? И как в целом и где инициализировать такой объект? Я в разнообразных исходниках нахожу только с даггером примеры, походу придется его юзать)

ты что-то такое имел в виду?

Да, как вариант

а еще варианты есть, или это лучший?

Лучших нет, есть подходящие для вашей задачи) усложнять можно долго: интерфейс сделать вашему хелперу, чтобы тестировать проще было, спрятать его за всякими интеракторами, чтобы префы напрямую в презентере не использовать. Это всё на ваше усмотрение, но и так хорошо, если вам хватает)

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

интересно что так сломало Алексея что он стал советовать плохие практики
помнится видео на курсере просили исправить потому как там в презентер контекст передавался
надо понимать что первоначальный совет Алексея не имеет отношения к архитектуре приложения и правильному использованию библиотеки
я понимаю такой ответ как делай как хочешь
странно что так советует админ канала и основной контрибьютер библиотеки
знатно видно потрепало на новой работе

ответ длинный и не особо отностся к библиотеке мокси
на самом деле все зависит от того для чего вы затащили библиотеку в проект
если для того чтобы просто переживать перевороты и восстанавливать стейт экрана то можете не париться и делайте как вам удобно
если решили поиграть в архитектуру и выбор пал на MVP то играйте в архитектуру правильно

в вашем случае лучше ввести прослойку для доступа к данными
репозиторий/интеррактор как угодно назовите
смысл в том чтобы развязать зависимости
презентер должен зависить от интерфейса хранилища, а не от имплементации
при этом презентер не должн беспокоиться от чего зивисят зависимости от которых зависит он

вы же решаете проблему как пробросить зависимость которая нужна не презентеру, а другому типу от которого зависит презентер

примеры что вы встречаете в основном дагер потому что он самый популярный
это библиотека которая как раз и позволяет решить проблемы с зависимостями

есть много других боле простых библиотек которые просто облегчают работу
все можно сделать самому лишь потому что процесс DI существовал и применялся задолго до этих библиотек

Воу, откуда столько яда?
Человек спросил, как передать контекст в презентер, конкретный вопрос задал, жизни его учить не просил. Библиотека не ограничивает этого, и это не является общепринято плохой практикой.
Не стоит этого делать в большом проекте, потому что тестирование и архитектура? Конечно, согласен.
Поиграться на коленке с Мокси, научиться передавать зависимости в презентер? Да сколько угодно пусть контекст передаёт.

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