Количество классов, функций и строк кода совершенно не связано с простотой и поддерживаемостью кода. Я могу написать фарш в 1 методе 1 класса, могу сделать красиво и понятно в 10. Вы навешиваете какие-то ярлыки и говорите что это МВП а это не МВП. Я же предлагаю названия немного в сторону отставить, и посмотреть в суть: код, где каждый занимается своим делом, проще и понятнее кода, где один класс и швец и жнец и на дуде. Есть популярные схемы такого разделения, MV*. Вы можете придумать свои названия классам, по которым вы разделили ответственность, и сказать что ваш подход XYZ намного лучше MVP. Ваше право, но категоричные утверждения, вроде "MVP только для тестирования" только путают начинающих программистов, ещё цитировать вас где-то начнут.

Такое утверждение тоже легко опровергнуть, вот у меня MVP а тестов нет, или есть но писать их неудобно.

И всё, MVP не нужен. Неконструктивно же)

а давайте на примере
есть экран с кнопкой
по нажатию на кнопку надо показать Toast
что проще и понятней с MVP или без?

А вы часто такие простые экраны пишете?) Я сейчас спорить не хочу, я спать хочу. Если хотите действительно подискутировать - накидывайте, завтра продолжим.

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

выглядит так, что нуужно перейти в Android Architecture

отпустите Алексея спать )

Окей, если никто не ответит, придумаем, где обсудить. Возможно даже в личке)

аргументы - тестировать MVP не удобно by design - нужно обмазаться моками, верифаями и прочей сранью.

проще и понятнее - слишком субъективная оценка чего-либо)

p.s. так же, как и удобно/не удобно тестировать)

жоско, в закрепы надо. могу еще народ собрать 🙂

Приглашаю @hram0v сформулировать свой тезис и обсудить вместе со всеми желающими в более подходящем месте. Тут всё-таки про Мокси, и мы нещадно нафлудили) Завтра попробую сформулировать и свой ответ

Конкретные примеры - это экран с одной кнопкой и тостом? В таким примерах не то что MVP не нужен, но и Android разработчик тоже. Все проблемы, которые вы описали выше, ведут к одному тезису: больше строк кода -> сложней поддерживать. Как раз таки на реальных примерах, а не на надуманных Hello World, это неверно. Аргументировать смысла не вижу, это мнение недоказуемо однозначно, как и ваше. Необходимость в MVP и все споры по этому поводу - это скорее тема архитектурного чата.

Мне кажется, что тот товарищ просто толсто всех тролил

мы там в чатике разобрались, кто что имел в виду, заходите посмотреть)

Привет ещё раз! А можно как-то обойти ситуацию, когда после onStop нельзя обратиться через getViewState к Фрагменту?

getViewState возвращает ViewState — машину, которая отвечает за передачу очереди команд во View. Fragment может обрабатывать команды только между onStart/onResume и до onStop/onDestroyView/onDestroy.

Не рекомендую делать какую-то логику за пределами "жизни" (видимости/активности) фрагмента (View).

А какая задача стоит?