Динамическая форма рендеринга форм в мобильном приложении - PullRequest
Новая
       24

Динамическая форма рендеринга форм в мобильном приложении

0 голосов
/ 24 сентября 2019

Я работаю бэкэнд-разработчиком, и у нас есть iOS и Android веб-интерфейсы.Недавно у нас возникла идея, что было бы неплохо создать в мобильном приложении какую-то платформу, способную отображать типичные вопросы формы на основе JSON, возвращаемого бэкэндом.JSON будет содержать список вопросов, которые следует задать во время поездки.То есть мы согласны с типами вопросов, и бэкэнд возвратит строки / конфигурации, которые веб-интерфейс будет использовать для построения вопросов определенных типов.

По сути, для возврата бэкэнда после JSON: 

{
    "questions": [
        {
            "id": "54543543",
            "type": "COMBOBOX",
            "title": "Random title",
            "subtitle: "Random subtitle",
            "options": [
                "Text 1",
                "Text 2"
            ],
            "selected": 1
        }
        ...
    ]
}

Это даст нам дополнительную гибкость, если мы захотим:

  • Перестройка потока форм (добавление / удаление / перефразирование / перемещение вопросов существующих типов) - нам не нужно будет заставлять клиентовобновите приложение, если мы хотим что-либо изменить в форме.
  • A / B-тест, чтобы увидеть, как улучшается коэффициент конверсии или как изменяются ответы нашего партнера по интеграции на основе ответов, предоставленных клиентами (их многонеобязательных параметров, которые могут повлиять на результаты).
  • Повторно использовать тот же движок для создания аналогичных форм для въезда в другие страны - меньше шаблонов, только чисто презентационная логика на стороне мобильного приложения.

Однако у этого подхода есть и недостатки:

  • Технически решениесложный - несмотря на то, что он уменьшает шаблон, он вносит техническую сложность.Раньше в компании не было ничего подобного, и многие будут против этого (компания, как правило, предпочитает сдерживать сложность и использовать только стандартные подходы / инструменты, а не создавать собственные решения).
  • Это не совсем гибко, тем не менее, интерфейс должен будет программировать определенные типы вопросов (макеты) в приложении.Некоторые ответы JSON для определенных макетов будут очень сложными и вложенными, чтобы убедиться, что веб-интерфейс способен создавать красивые и функциональные вопросы.
  • Для новичков на веб-интерфейсе и бэкэнде будет намного сложнее поддерживать эту частьсистемы.
  • Меньше людей захотят просмотреть код - учитывая тот факт, что для запросов извлечения веб-интерфейса требуется как минимум 2 утверждения - может потребоваться больше времени для создания / исправления чего-либо там.

Что ты думаешь?Моя главная забота - опыт клиентов - нам не нужно будет просить клиентов обновить приложение.50% -60% наших клиентов имеют автообновления.Кроме того, гибкость в исправлении опечаток / корректировке форм может быть очень полезной, особенно если партнеры по интеграции решают изменить свой API или если мы хотим, чтобы мы сами изменили путь и попросили больше / меньше информации.Однако это означает, что нам придется создать собственную структуру, которая в какой-то момент может выйти из-под контроля, особенно если основатели покидают компанию / команду.

...