Комментарии 10
User Information Component, Menu Component, Action Button Component — это всё отдельные кастомные View или унифицированные элементы в RecyclerView? И второй вопрос: какого размера JSON с описанием всех экранов приложения обычно получается?
Для RecyclerView это могут быть: UserInformationViewHolder + UserInformationPresenter + UserInformationInteractor
То же самое если кажый компонент — это MVVM: UserInformationView + UserInformationViewModel + UserInformationInteractor/Repository
Размер JSON — это не самая критичная вещь, ведь можно использовать gzip для сжатия HTTP тарафика, а если совсем прижмет, то использовать ProtoBuf, но это совсем редкий случай.
Еще раз на счет компонентов, их стоит рассматривать как View + какие-то сущности отвечающие за логику. Можно использовать любую архитектуру. Но, т.к. тут по большому счету работа со стейтом, я бы рекомендовал MVI
В зависимости от подхода, Middleware и Reducer может быть один на весь экран или даже приложение, или же каждая бизнес сущность будет иметь свой Middleware и Reducer
А вот можно поподробнее про "один на всё приложение"? Насколько это подходит для мобильных приложений на ваш взгляд? Есть ли примеры таких приложений?(Только больших, а не с 2-3 экранами).
Так же часто у каждого компонента свой стейт и свой Reducer он его обновляет независимо.
Для Server Direven UI архитектур — часто один reducer на экран
Ещё несколько вопросов:
1) Что делает блок Business logic внутри компонента? Только преобразуется state в business object? Что если объединить его с ViewModel и сразу делать state->viewobject?
2) Представим ситуацию. У вас на экране два компонента. В одном чекбокс, а в другом кнопка. По чекбоксу надо делать enable/disable кнопки. Как будет выглядеть путь? Пройдёт ли он через всё, или это сразу будет выполнено во view слое?
2) Да, так как у нас Unidirectional data flow, то пройдет весь путь
— пользователь тапнул на чекбокс
— View отправит Action
— Бизнес логика его поймает и сделает две вещи:
1. скажет своей ViewModel что пора изменить UI стейт. И ViewModel отрисует выбранный чекбокс
2. отправит Action дальше в некий Service экрана
— Service экрана примит Action и передаст его компоненту с кнопкой
— компонент с кнопкой, на основе этого Action обновит состояние кнопки
Любопытная идея с составлением разметки на сервере. Видимо, основная идея была в избежании потребности обновления клиента. Разумеется, интересны моменты "НО":
- Часто ли возникают ситуации, когда под новые фичи всё равно приходится обновлять клиент?
- Какова политика по поддержке старых версий? Особенно любопытно, как поведёт себя старая версия, которая получит с сервера информацию о новом (неизвестном ей) компоненте.
- Насколько это оправданно, если проект по тем или иным причинам предполагается только на Android? То есть, клиент нужно писать только один.
- Сравнима ли сложность написания "парсинга" конфигурации с сервера с простым написанием такого же приложения с нуля? Получится ли потом повторно использовать такой же механизм на новом проекте?
А как решать проблему с анимациями между компонентами? Например, есть экран на котором есть несколько компонент взаимодействия с которым приводят к анимациям с изменением вёрстки(смещения, расскрытия, сдвиги и т.д). Как применять server driven UI в таких случаях? Уже нельзя просто взять и убрать/добавить компонент из ответа сервера. Анимация сломается.
Масштабируемая архитектура для больших мобильных приложений