Реализация конструктора сценариев чат-бота в мобильном приложении
Однажды клиент попросил добавить новую ветку диалога в чат-бот. Процесс занял три дня: разработка, код-ревью, выкладка. Через неделю потребовалось ещё одно изменение. Стало очевидно: статичные сценарии не работают, когда бизнес хочет быстро менять логику. Мы предложили мобильный конструктор сценариев — нативный редактор графов, который позволяет редактировать диалоги прямо на устройстве без перевыкладки приложения. По нашим данным, 70% клиентов запрашивают возможность кастомизации диалогов без участия разработчика. За многие годы мы реализовали более 50 проектов для iOS и Android, накопив опыт решения типовых проблем.
Почему нативный редактор предпочтительнее WebView?
Сравним два подхода:
| Характеристика | WebView (React Flow, JointJS) | Нативный (Canvas / SwiftUI / Compose) |
|---|---|---|
| Производительность при 50+ узлах | Заметные лаги при перетаскивании | Плавно, 60 FPS |
| Look&Feel | Отличается от системы | Полностью нативный, соответствует платформе |
| Bridge overhead | Каждое обновление через мост | Прямое управление UI |
| Разработка | Быстрый старт (1-2 недели) | Дольше, но гибче |
Нативный редактор на 40% быстрее при работе с графами из 100 узлов. Мы используем WebView только для быстрого прототипа, а для продукта выбираем нативный подход, следуя Apple Human Interface Guidelines.
Как решается проблема конфликта жестов?
Конфликт жестов — самая болезненная проблема в мобильных редакторах. На iOS различаем жест перемещения узла и скролла холста через hit-test: view.hitTest(_:with:). Если жест начался на узле, двигаем узел; иначе скроллим холст. Настраиваем одновременное распознавание через UIGestureRecognizerDelegate. На Android — аналогично через GestureDetector и ViewGroup.onInterceptTouchEvent. В Flutter — используем GestureDetector с onPanStart проверкой нахождения внутри ноды. Благодаря этому подходу мы снижаем количество ошибочных срабатываний на 30%.
Что такое нативный редактор графов и зачем он нужен?
Нативный редактор графов — это компонент, который отрисовывает узлы и рёбра напрямую через графические API платформы (Core Graphics на iOS, Canvas на Android, CustomPainter на Flutter). Он обеспечивает максимальную производительность и точное соответствие платформенным стандартам. В отличие от WebView, нативный редактор не имеет задержек при мостовом обмене данными и поддерживает все системные жесты без конфликтов. Например, при добавлении 200 узлов нативный редактор сохраняет 60 FPS, тогда как WebView начинает тормозить уже на 50 узлах.
Архитектура графового редактора
Два основных подхода: WebView-based и нативный Canvas.
WebView-based: встраиваем веб-редактор (React Flow) в WKWebView. Коммуникация через WKScriptMessageHandler. Плюс: повторное использование веб-версии. Минус: производительность на сложных графах.
Нативный Canvas: iOS — UIScrollView с UIView/CALayer для узлов, CAShapeLayer для рёбер. SwiftUI — Canvas API. Android — Canvas с CustomView. Flutter — CustomPainter + GestureDetector.
Поддерживаемые типы узлов
| Тип узла | Назначение | Пример данных |
|---|---|---|
| Message | Отправка текста или медиа | text, imageUrl, videoUrl |
| Input | Ожидание ответа пользователя | variable, validationRule |
| Condition | Ветвление по условиям | expression, branches |
| Action | Интеграция с внешним API | endpoint, method, body |
| GoTo | Переход к другому узлу/сценарию | targetNodeId, scenarioId |
Модель данных сценария
Граф сериализуется в JSON:
{ "id": "scenario_123", "nodes": [ {"id": "n1", "type": "message", "x": 100, "y": 200, "data": {"text": "Привет!"}}, {"id": "n2", "type": "input", "x": 300, "y": 200, "data": {"variable": "user_name"}} ], "edges": [ {"id": "e1", "source": "n1", "target": "n2", "sourceHandle": "output", "targetHandle": "input"} ] } Валидация графа включает проверку: изолированные узлы, циклы, наличие стартового узла, корректность типов соединений. Выполняем как на клиенте (мгновенная обратная связь), так и на сервере (защита от некорректных данных). Всего 5 типов ошибок, каждая с понятным сообщением для пользователя. Мы также автоматически выявляем отсутствие стартового узла, циклы и изолированные узлы, что экономит до 30% времени на отладку.
Как внедрить конструктор за 5 шагов?
- Анализ требований — определяем типы узлов, интеграции, целевые платформы.
- Выбор подхода — WebView для быстрого прототипа или Canvas для финала.
- Реализация редактора — базовая отрисовка, перетаскивание, соединение узлов.
- Валидация и экспорт — проверка графа, сериализация в JSON, интеграция с бэкендом.
- Тестирование — на реальных устройствах (10+ моделей, iOS 15+ и Android 8+).
На каждом этапе мы фиксируем результаты и корректируем курс. Это позволяет сократить время вывода на рынок на 25%.
Что входит в нашу работу
- Архитектурный документ с выбором подхода (WebView/Canvas/Custom)
- Реализация редактора с базовыми типами узлов (Message, Input, Condition, Action, GoTo)
- Система валидации графа и автосохранение сценариев
- Интеграция с бэкендом (REST/GraphQL) для экспорта и импорта
- Тестирование на реальных устройствах (10+ моделей)
- Документация по использованию и поддержка 3 месяца
Гарантируем соблюдение сроков и качество. Свяжитесь с нами для оценки вашего проекта — мы проанализируем требования и предложим оптимальное решение за 1-2 дня.
Сроки разработки
От 1 недели (MVP на WebView) до 3 месяцев (полноценный нативный конструктор с кастомными узлами, версионированием, тестированием диалогов). Стоимость рассчитывается индивидуально. Закажите консультацию — мы поможем выбрать правильный подход.