Или даже viewState.post{ showStuff() }

Как обозначено выше, тут есть риск, что в этой лямбде позовут что-то ещё.

Как мне кажется, было бы удобнее задать свой раннер, на котором бы по умолчанию исполнялись ВСЕ вызовы view. По умолчанию он - из UI потока всё выполняет.

А для редких случаев дёрганья view не из UI потока - сделать отдельный метод, типа

viewState.execOnRunner(Runner { /* run on io */ }) { doSomethingWithViewOnNonUiThread()}.

Тут, скорее следует исходить из наиболее частого кейса использования. А чаще всего view нужно дёргать из UI потока.

Много нюансов будет, в общем) разные виды возможно сделать, небезопасный, корутинный, обычный handler.post-ный

это наверно будет провокационный вопрос, но хочется услышать мнение экспертов 🙂 смотрите, несколько лет назад “типичная” архитектeра андроид приложения выглядела так: слоистый подход на базе MVP (пусть мокси), Cicerone от Кости, Rx для “соединения” слоёв и асинхронщины. Гугл запрыгивает в “ушедший” поезд и выпускает Arch Components и говорит, что теперь “правильно” это MVVM с ViewModels, LiveData, Nav Component, Coroutines и Flow и судя по всему - бОльшая часть комьюнити “молется” на этот подход от гугла и все кинулись всё переделывать и “тыкать” как теперь “правильно” и модно-молодёжно. Теперь вопрос: в реальной жизни кто-то пользуется MVVM на базе Arch Components на сложных проектах? Какие плюсы MVVM гугловского по сравнению с “классикой” Moxy+Cicerone+Rx ? Есть ли смысл щас всё переписывать на готовых запущенных проектах чтобы типа “в перспективе” был какой-то там профит, год, два, три спустя? Спасибо заранее 🙂

Выработанная архитектура со стабильными библиотеками почти всегда лучше, независимо от того, говорим мы про MVP или MVVM.
Специально сравнивал несколько проектов, вывод: плюс-минус одно и то же. Либо завязываетесь на всё от гугла, либо на всё от наших ребят.

Coroutines и Flow отлично ложится на архитектуру с Moxy и Cicerone так же легко, как и RX (я бы даже сказал, что легче)

Мнение выше субъективно, но что я могу сказать точно: переписывать готовый проект только ради того, чтобы переехать на другой стек - это бред. Переписывать может быть смысл из-за плохой архитектуры, но точно не из-за "MVP"

Я бы не стал рассматривать это всё в неделимой связке, все технологии в целом независимо заменяемы.
MVVM и MVP практически эквивалентны, в новом проекте я бы стал использовать VM потому что там нет кодогенерации, и подход больше ориентирован на представление состояния экрана в виде именно состояния, а не набора команд. Этот же подход использует Compose, можно к нему готовиться понемногу.
Cicerone в целом круче навкомпонентов, но тоже зависит от сложности вашей навигации, вдруг вы очень хотите compile-time картинку с графом.
Корутины вообще ван лав, учитывая, что у них есть свой Rx, одно удовольствие.
LiveData довольно странная штука, можно в целом тащить SharedFlow вместо неё.
Но это если речь о green-field проектах. Готовый запущенный проект - это всегда большая ответственность. Разумеется, он должен развиваться в ту сторону, в которую вы хотите, но исходить надо из конкретных потребностей проекта. Если у вас прекрасно работает какой-то стек - зачем его менять?

Выпустили версию 2.2.1!
В новой версии добавили экспериментальную опцию для более быстрого annotation processing’а, как вкючить описано в readme в секции “New Features”. Пробуйте и заводите issue, если со включенной опцией что-то работает не так.

Всем привет. Я с MVP мало знаком. Можете что-то покидать посмотреть или почитать, пожалуйста?

он его вроде на KMP переписал? и на ютубе 2 часа рассказывал что и почему у него не заработало и как он лихо искал аналоги библиотек

С архитектурной точки зрения после переписывания на KMP там ничего не поменялось

ни у одного меня похоже есть пробелы в понимации работы фрагментов

Да, я наврал, когда мы там дискутировали) Гуглы молодцы, новую доку выкатили, надо прям от и до читать.

я так понимаю presenter и погибал в onDestroy(), так как фрагмент не был добавлен в backstack

подскажите как грамотно архитектурно делать такое: есть несколько фрагментов для оформления заказа и на каждом надо помнить что мы там покупаем - где держать модельку с продуктом который покупают? открывать DI скоуп и из презентеров доставать из скоупа? или между всеми презентерами таскать аргумент в бандле фрагментов? или в каких нить интеракторах это хранить и чистить руками?

Храни в репозитории, который будет инжектиться сразу во все use case. По di - решай сам, это уже на свой вкус

@senneco  спасибо 🙂

привет, как быть с презентером в ситуации когда фрагмент во вью пейджере и из вне пытаюсь достучаться до презентера а MvpDelegate.onCreate() еще не вызван?

private val presenter: SendEGCPresenter by moxyPresenter { presenterProvider.get() }


override fun onPageChanged() {
        // что можно тут проверить ?
   presenter.onPageChanged()
}

Как вариант, можно подождать пока MvpDelegate.onCreate() вызовется. Через CompletableSubject, например.

class MyFragment : ...{


    private val viewInitializedCompletableSubject = CompletableSubject.create()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    ....
    
        viewInitializedCompletableSubject.onComplete()
    }


    override fun onPageSelectionChanged(isPageNowSelected: Boolean) {
        viewInitializedCompletableSubject.subscribe(
                onComplete = {
                    when (isPageNowSelected) {
                        true -> presenter.onViewHasAppeared()
                        false -> presenter.onViewHasGone()
                    }
                }
        )
    }

Коллеги знаю что не по теме чата, сталкивался ли кто со сменой иконки приложения?