поправляю

-_-

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

Ок

шо? там краш и утечка должна быть)

про покрытие тестами в комментах спорная тема
покрытие зависит не от архитектуры а от навыков программиста

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

и тот кто это писал с пеной у рта утверждал что так правильно

так что MVP не панацея

блин, подход-то с моделью отличный, если там простой маппинг, а-ля enum -> строка из ресурсов

нет так делать нельзя
точней можно но не на моих проектах 😊

чому незя то? оно ж клево тестируется

видимо это был сарказм?

нет, что тут не тестируется?

class.getFormattedValue() == нужное, где getFormattedValue - extansion

Ну, читайте документацию и используйте либу корректно.

Изи делается mvp вьюшка при помощи мокси

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

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

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

Когда? Можно ссыль?

да и я про это
но в статье тишина

вот

что-то отдается в метод view.setNewClass и будет протестировано юнитами

и так же юнитами будет протестировано, что определенный class дает нужные данные при использовании на нем extension функций

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