1. Модель ответа сервера сразу включает в себя описание экрана с бизнес-данными. Обновление данных на форме происходит путём обновления экранной формы или компонента с помощью ответа от сервера.
2. Расскажу на примере двух текстовых полей и пуллеров. Снизу JSON, который демонстрирует похожую реализацию.
Этот JSON и есть ответ сервера при открытии экранной формы. Что он содержит?
В текстовом поле textFieldCity прописывается событийная обработка: при тапе на него нужно показать пуллер выбора города – pullerChooseCity. В «событийке» пуллера прописано, что нужно изменить текстовое поле textFieldCity значением, на которое тапнул пользователь в пуллере. В этом случае у нас произойдёт простое заполнение текстового поля выбранным значением. Однако для того, чтобы подгрузить улицы для выбранного города, необходимо провести сетевой запрос, который обновит экранную форму. Для этого у текстового поля textFieldCity в «событийке» есть событие CHANGE, которое срабатывает при изменении текстового поля. В этом случае при изменении нужно вызвать запрос POST rest\/v3\/screen\/ChosenCity и ответом от него произвести операцию над экраном SCREEN – REPLACE. Соответственно, с точки зрения разработки мы ожидаем, что с бэка придёт экранная форма с текстовым полем textFieldStreet и пуллером pullerChooseStreet, актуальными для выбранного города в текстовом поле textFieldCity.
3. Что касается передачи данных с формы мобильного приложения на бэк – как такового жёсткого контракта нет. В любом действии, которое подразумевает сетевой запрос, есть объект "body", который представляет из себя формат type obj = {[keys: string]: any};. При этом данные из конкретного компонента будут подставляться по его идентификатору. На примере кейса выше:
В случае возникновения транспортной ошибки (недоступность бэка) на мобильном приложении будет показана стандартная ошибка с шаблонным текстом. Все бизнес-ошибки мы рекомендуем командам обрабатывать двумя способами:
1. Отрисовывать новый экран, где начнётся альтернативный сценарий или подсветятся проблемные зоны.
2. Возвращать общую модель ошибки с бэка, для которой в мобильном приложении также есть обработчик. В конечном счёте покажется системный диалог с сообщением для клиента.
Сейчас в части продуктов на этом решении у нас выведены «Подбор кредита», «Подключение АУСН», раздел «Налоги и взносы» в виджете «Мои дела» и список заказов для отраслевого решения «Транспорт».
Интерес к решению внутри банка достаточно высок у команд, которые испытывают трудности в найме мобильных разработчиков, поэтому новые продукты на SDUI появляются каждый квартал. Всё правильно, UI и UX в случае применения SDUI достаточно ограничен, не всё можно реализовать с таким подходом. Уже реализованные экраны как раз представлены в статье в разделе «Результаты». Конечно, это не всё, но принципиально именно эти экраны мы сейчас умеем делать.
Безусловно, именно мобильные разработчики создают фреймворк в СберБизнес. Сейчас в команде, которая делает решение, по два человека разработки с iOS и Android соответственно. Нативные формы у нас пилят несколько десятков команд, в каждой примерно по одному разработчику iOS и Android. Вопрос экономии очень относителен. Те, кто уже вывел формы на нативе, не особенно хотят переезжать на SDUI, но это и не требуется. Однако, как упомянуто в статье, примерно 80 % существующих экранов можно сделать на нашем фреймворке. То есть у восьми из десяти новых команд, которые хотят появиться в СберБизнес со своим продуктом, нет необходимости в найме мобильных разработчиков для старта MVP и проверки ценности функциональности в мобильном формфакторе.
Мы активно развиваемся и наполняем фреймворк новыми фичами на основе CR от команд и развития дизайн-системы. Какие-то сценарии реализовать на SDUI не получится, и нужно прибегать к нативным разработчикам. Это решение мы оставляем на откуп продуктовым командам. По опыту, команды руководствуются P&L продукта в мобильном приложении. Если рентабельность продукта или её перспективы позволяет нанять разработчиков, то нативу быть!
Да, конечно. У нас действительно есть основные и альетрнативные кнопки. И тот и другой тип могут быть как кликабельными так и некликабельными)
Спасибо, что заметили!
Отвечу по пунктам.
1. Модель ответа сервера сразу включает в себя описание экрана с бизнес-данными. Обновление данных на форме происходит путём обновления экранной формы или компонента с помощью ответа от сервера.
2. Расскажу на примере двух текстовых полей и пуллеров. Снизу JSON, который демонстрирует похожую реализацию.
Этот JSON и есть ответ сервера при открытии экранной формы. Что он содержит?
В текстовом поле textFieldCity прописывается событийная обработка: при тапе на него нужно показать пуллер выбора города – pullerChooseCity. В «событийке» пуллера прописано, что нужно изменить текстовое поле textFieldCity значением, на которое тапнул пользователь в пуллере. В этом случае у нас произойдёт простое заполнение текстового поля выбранным значением. Однако для того, чтобы подгрузить улицы для выбранного города, необходимо провести сетевой запрос, который обновит экранную форму. Для этого у текстового поля textFieldCity в «событийке» есть событие CHANGE, которое срабатывает при изменении текстового поля. В этом случае при изменении нужно вызвать запрос POST rest\/v3\/screen\/ChosenCity и ответом от него произвести операцию над экраном SCREEN – REPLACE. Соответственно, с точки зрения разработки мы ожидаем, что с бэка придёт экранная форма с текстовым полем textFieldStreet и пуллером pullerChooseStreet, актуальными для выбранного города в текстовом поле textFieldCity.
3. Что касается передачи данных с формы мобильного приложения на бэк – как такового жёсткого контракта нет. В любом действии, которое подразумевает сетевой запрос, есть объект "body", который представляет из себя формат type obj = {[keys: string]: any};. При этом данные из конкретного компонента будут подставляться по его идентификатору. На примере кейса выше:
В этом случае выполняется вот такой запрос на бэк (лог из мобильного приложения):
В случае возникновения транспортной ошибки (недоступность бэка) на мобильном приложении будет показана стандартная ошибка с шаблонным текстом. Все бизнес-ошибки мы рекомендуем командам обрабатывать двумя способами:
1. Отрисовывать новый экран, где начнётся альтернативный сценарий или подсветятся проблемные зоны.
2. Возвращать общую модель ошибки с бэка, для которой в мобильном приложении также есть обработчик. В конечном счёте покажется системный диалог с сообщением для клиента.
Что вы имеете в виду, говоря о хендлере SUBMIT?
Сейчас в части продуктов на этом решении у нас выведены «Подбор кредита», «Подключение АУСН», раздел «Налоги и взносы» в виджете «Мои дела» и список заказов для отраслевого решения «Транспорт».
Интерес к решению внутри банка достаточно высок у команд, которые испытывают трудности в найме мобильных разработчиков, поэтому новые продукты на SDUI появляются каждый квартал. Всё правильно, UI и UX в случае применения SDUI достаточно ограничен, не всё можно реализовать с таким подходом. Уже реализованные экраны как раз представлены в статье в разделе «Результаты». Конечно, это не всё, но принципиально именно эти экраны мы сейчас умеем делать.
Безусловно, именно мобильные разработчики создают фреймворк в СберБизнес. Сейчас в команде, которая делает решение, по два человека разработки с iOS и Android соответственно. Нативные формы у нас пилят несколько десятков команд, в каждой примерно по одному разработчику iOS и Android. Вопрос экономии очень относителен. Те, кто уже вывел формы на нативе, не особенно хотят переезжать на SDUI, но это и не требуется. Однако, как упомянуто в статье, примерно 80 % существующих экранов можно сделать на нашем фреймворке. То есть у восьми из десяти новых команд, которые хотят появиться в СберБизнес со своим продуктом, нет необходимости в найме мобильных разработчиков для старта MVP и проверки ценности функциональности в мобильном формфакторе.
Мы активно развиваемся и наполняем фреймворк новыми фичами на основе CR от команд и развития дизайн-системы. Какие-то сценарии реализовать на SDUI не получится, и нужно прибегать к нативным разработчикам. Это решение мы оставляем на откуп продуктовым командам. По опыту, команды руководствуются P&L продукта в мобильном приложении. Если рентабельность продукта или её перспективы позволяет нанять разработчиков, то нативу быть!