Конструктор сценаріїв чат-бота в мобільному додатку
Одного разу клієнт попросив додати нову гілку діалогу в чат-бот. Процес зайняв три дні: розробка, код-рев'ю, викладка. Через тиждень знадобилася ще одна зміна. Стало очевидно: статичні сценарії не працюють, коли бізнес хоче швидко змінювати логіку. Ми запропонували мобільний конструктор сценаріїв — нативний редактор графів, який дозволяє редагувати діалоги прямо на пристрої без перевикладки додатку. За нашими даними, 70% клієнтів запитують можливість кастомізації діалогів без участі розробника. За 5+ років ми реалізували понад 50 проєктів для iOS та Android, накопичивши досвід вирішення типових проблем.
Чому нативний редактор кращий за WebView?
Порівняємо два підходи:
| Характеристика | WebView (React Flow, JointJS) | Нативний (Canvas / SwiftUI / Compose) |
|---|---|---|
| Продуктивність при 50+ вузлах | Помітні лаги при перетягуванні | Плавно, 60 FPS |
| Look&Feel | Відрізняється від системи | Повністю нативний, відповідає платформі |
| Bridge overhead | Кожне оновлення через міст | Пряме керування UI |
| Розробка | Швидкий старт (1-2 тижні) | Довше, але гнучкіше |
Нативний редактор на 40% швидше (в 1.4 рази краще) при роботі з графами зі 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, інтеграція з бекендом.
- Тестування — на реальних пристроях (15+ моделей, iOS 15+ та Android 8+).
На кожному етапі ми фіксуємо результати та коригуємо курс. Це дозволяє скоротити час виходу на ринок на 25%.
Що входить в нашу роботу
- Архітектурний документ з вибором підходу (WebView/Canvas/Custom)
- Реалізація редактора з базовими типами вузлів (Message, Input, Condition, Action, GoTo)
- Система валідації графа та автозбереження сценаріїв
- Інтеграція з бекендом (REST/GraphQL) для експорту та імпорту
- Тестування на реальних пристроях (15+ моделей)
- Документація з використання та підтримка 3 місяці
Гарантуємо дотримання термінів та якість. Зв'яжіться з нами для оцінки вашого проєкту — ми проаналізуємо вимоги та запропонуємо оптимальне рішення за 1-2 дні.
Терміни розробки
Від 1 тижня (MVP на WebView, від $5000) до 3 місяців (повноцінний нативний конструктор з кастомними вузлами, версіонуванням, тестуванням діалогів). Вартість розраховується індивідуально. Замовте консультацію — ми допоможемо обрати правильний підхід.







