Обновить

Комментарии 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 — вы «попадёте» на запущенный вами сервер из примере

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации