
Комментарии 4
Отлично, мне особенно понравилось что ты спрашиваешь MVVM и MVI. Но почему ты выбрал второе? В чём его реальные плюсы?
На мой взгляд, куча разных сущностей - продусер/редусер/актор, что наблюдаю в некоторых реализациях MVI, - просто бесполезный мусор.
MVVM даёт одностороннюю зависимость, при этом необходимость в обратной зависимости реализуется колбэками, то есть всё предельно просто, но при этом слабосвязно.
В обсуждении с другими разработчиками поднимаю эту тему, но никто не хочет хоть как-то хвалить MVI)
Это тестовый проект. Особо не выбирал решил разобраться и применить. Согласен, с тем что MVI для простого проекта избыточен
однако с MVI будет проще логировать запросы в modelView потому что точка единственная handleEvent()
Можно хранить эти эвенты и откатываться назад на подобии Undo
Все таки есть очередность действий когда обращение идет через одну точку handleEvent()
Можно же сделать интерфейс для вьюмодели:
interface UiEventHandler {
onEvent(event: UiEvent)
}И разные вьюмодели его реализуют, тогда в каком-то каcтомном компоненте, который часто используется:
@Composable
fun SameFun(
eventHandler: UiEventHandler
) {}
И события этого компонента могут обрабатываться в разных вьюмоделях.
Android Эмулятор не видит адрес http://0.0.0.0:8080/
Для доступа к хост-машине(вашему ПК, на котором запущен эмулятор) на Android зарезервирован IP=10.0.2.2
То есть, если вы введёте 10.0.2.2:8080 — вы «попадёте» на запущенный вами сервер из примере
Compose Multiplatform простое приложение c MVI