Масштабируемая архитектура для больших мобильных приложений

[anil]

Спасибо за статью! А каковы особенности реализации? User Information Component, Menu Component, Action Button Component — это всё отдельные кастомные View или унифицированные элементы в RecyclerView? И второй вопрос: какого размера JSON с описанием всех экранов приложения обычно получается?

[AlexeyGlukharev]

User Information Component, Menu Component, Action Button Component — это не только View, но и классы отвечающие за бизнеслогику, к примеру: UserInformationView + UserInformationPresenter + UserInformationInteractor

Для RecyclerView это могут быть: UserInformationViewHolder + UserInformationPresenter + UserInformationInteractor

То же самое если кажый компонент — это MVVM: UserInformationView + UserInformationViewModel + UserInformationInteractor/Repository

Размер JSON — это не самая критичная вещь, ведь можно использовать gzip для сжатия HTTP тарафика, а если совсем прижмет, то использовать ProtoBuf, но это совсем редкий случай.

Еще раз на счет компонентов, их стоит рассматривать как View + какие-то сущности отвечающие за логику. Можно использовать любую архитектуру. Но, т.к. тут по большому счету работа со стейтом, я бы рекомендовал MVI

[agent10]

В зависимости от подхода, Middleware и Reducer может быть один на весь экран или даже приложение, или же каждая бизнес сущность будет иметь свой Middleware и Reducer

А вот можно поподробнее про "один на всё приложение"? Насколько это подходит для мобильных приложений на ваш взгляд? Есть ли примеры таких приложений?(Только больших, а не с 2-3 экранами).

[AlexeyGlukharev]

Один на все приложение, это скорее специфичный случай, такое не редко в вебе, но для мобильных я вряд ли встречал что-то подобное. Но в мобильных приложения часто встречается один Reducer на экран, и он принимает в себя все входящие состояния из множества Middleware и строит общий стейт всего экрана.

Так же часто у каждого компонента свой стейт и свой Reducer он его обновляет независимо.

Для Server Direven UI архитектур — часто один reducer на экран

[agent10]

А почему в мобилках не используется подход один на всё, а чаше разделяют по экранам?
Я просто не знаю веб, и интересно почему там это ок, а у нас в мобилках не ок..

[agent10]

Ещё несколько вопросов:
1) Что делает блок Business logic внутри компонента? Только преобразуется state в business object? Что если объединить его с ViewModel и сразу делать state->viewobject?
2) Представим ситуацию. У вас на экране два компонента. В одном чекбокс, а в другом кнопка. По чекбоксу надо делать enable/disable кнопки. Как будет выглядеть путь? Пройдёт ли он через всё, или это сразу будет выполнено во view слое?

[AlexeyGlukharev]

1) Это стандартное разделение бизнес и презентешйн логики. Ну если ни кто из команды не топит за Clean Arcitecture, и вы точно знаете, что логики много не будет, то можно объединить. Но в целом, обычно, вещи которые отвечают за модификацию и работу с UI находятся в ViewModel, а более выскокоуровневые штуки для работы с данными уже уровнем выше Interactor/Repository. Так же если выделить всю бизнеслогику в отдельный класс — это пять увеличит читабельность, будет легче тестировать, изменения в коде будут изолированы

2) Да, так как у нас Unidirectional data flow, то пройдет весь путь
— пользователь тапнул на чекбокс
— View отправит Action
— Бизнес логика его поймает и сделает две вещи:
1. скажет своей ViewModel что пора изменить UI стейт. И ViewModel отрисует выбранный чекбокс
2. отправит Action дальше в некий Service экрана
— Service экрана примит Action и передаст его компоненту с кнопкой
— компонент с кнопкой, на основе этого Action обновит состояние кнопки

[Guitariz]

ViewModel в общем случае содержит модели данных, которые можно отобразить. Презентацию сделает фрагмент или binding компонент.
Можно написать ViewModel и без использования UI и платформенных компонент — на пустых экшнах и моделях.

[ircover]

Любопытная идея с составлением разметки на сервере. Видимо, основная идея была в избежании потребности обновления клиента. Разумеется, интересны моменты "НО":

1. Часто ли возникают ситуации, когда под новые фичи всё равно приходится обновлять клиент?
2. Какова политика по поддержке старых версий? Особенно любопытно, как поведёт себя старая версия, которая получит с сервера информацию о новом (неизвестном ей) компоненте.
3. Насколько это оправданно, если проект по тем или иным причинам предполагается только на Android? То есть, клиент нужно писать только один.
4. Сравнима ли сложность написания "парсинга" конфигурации с сервера с простым написанием такого же приложения с нуля? Получится ли потом повторно использовать такой же механизм на новом проекте?

[agent10]

А как решать проблему с анимациями между компонентами? Например, есть экран на котором есть несколько компонент взаимодействия с которым приводят к анимациям с изменением вёрстки(смещения, расскрытия, сдвиги и т.д). Как применять server driven UI в таких случаях? Уже нельзя просто взять и убрать/добавить компонент из ответа сервера. Анимация сломается.