id: 233 slug: ar-external-database-integration-module-development title_ua: "Розробка модулів інтеграції з зовнішніми базами даних у AR" tags: [vr-ar]
Розробка модулів інтеграції з зовнішніми базами даних у AR
AR-програма для складського обліку показує працівникові інформацію про товар прямо над фізичною коробкою. Дані витягуються з ERP у реальному часі. Затримка запиту 800 мс — і анотація з'являється вже після того, як працівник відвів погляд. Це не UX-нюанс — це прямий провал сценарію використання. Інтеграція AR зі зовнішніми базами даних вимагає іншого підходу до архітектури запитів, ніж у звичайних мобільних програмах.
Ключові технічні виклики
Латентність запитів у AR критичніша, ніж у будь-якому іншому мобільному контексті. Користувач наводить камеру на об'єкт і очікує миттєвої відповіді. 300 мс — прийнятно, 800 мс — помітна затримка, 2 секунди — програма здається зламаною.
Основні джерела затримки:
- Мережевий round-trip до сервера (100–300 мс в 4G/5G, 20–50 мс в WiFi)
- Час обробки запиту на сервері (SQL-запит без індексу на таблиці з 5 мільйонів рядків — легко 500 мс)
- Десеріалізація JSON на клієнті
Рішення — предиктивне завантаження та кешування. У складському AR-додатку при наведенні на стелаж ми знаємо, що наступні 30 секунд користувач працюватиме з цією зоною. Prefetch запитує дані по всім артикулам зони одним batch-запитом одразу при розпізнаванні маркера стелажа, кладе в локальний кеш. Коли користувач наводить на конкретну коробку — дані вже готові.
Офлайн-режим — другий критичний момент. На складах, у промислових цехах, у медичних закладах з металевими перегородками сигнал нестійкий. AR-програма повинна працювати з кешованими даними та синхронізувати зміни при відновленні з'єднання. Конфлікти злиття (користувач змінив кількість в AR, інший користувач змінив те ж поле в ERP) — обробляються через timestamps + last-write-wins або через explicit conflict resolution UI.
Архітектура модуля інтеграції
Будуємо на трьох шарах:
Data Access Layer — абстракція над джерелом даних. IProductRepository з методами GetByBarcode(string code), GetByZone(string zoneId), UpdateQuantity(string id, int delta). Конкретна реалізація може бути REST, GraphQL, gRPC або прямо SQLite — шар AR-логіки не знає.
Sync Engine — управління кешем та синхронізацією. SQLite через sqlite-net-pcl на пристрої як локальне сховище. Фоновий SyncWorker опитує сервер кожні N секунд (налаштовується) або реагує на push через WebSocket/SignalR. Стратегія кешування — TTL за типом сутності: швидкозмінювані дані (кількість на складі) — 30 секунд, довідники (назви, характеристики) — 24 години.
AR Binding Layer — підключення даних до AR-об'єктів. У AR Foundation: при ARTrackedObjectsChangedEventArgs.added — запит даних для розпізнаного об'єкта через IProductRepository, заповнення ARAnnotationController отриманими даними. При removed — приховування анотації, скасування pending запитів через CancellationToken.
Для продуктивності використовуємо UniTask (або ValueTask у стандартному .NET) замість стандартних корутин — менше allocations, вбудована відмена задач через CancellationToken, правильна обробка винятків в async/await.
Типові AR-інтеграції
REST API (найпоширеніший): HttpClient з System.Net.Http, Newtonsoft.Json або System.Text.Json для десеріалізації. Важливо: HttpClient має бути singleton або pooled — кожен new HttpClient() відкриває новий socket pool.
GraphQL: для AR-програм особливо зручна — запитуємо лише потрібні поля, одним запитом отримуємо пов'язані дані. graphql-net-client або Strawberry Shake для .NET.
WebSocket / SignalR: для real-time оновлень — наприклад, AR-анотації на виробничій лінії, де статус обладнання змінюється щосекунди. SignalR Core на backend, Microsoft.AspNetCore.SignalR.Client на клієнті.
Пряме підключення до БД у AR-програмах не рекомендуємо — це антипаттерн з точки зору безпеки (облікові дані БД в APK) та масштабованості.
Етапи роботи
Аналіз джерел даних. Вивчаємо API або структуру БД, визначаємо вимоги до актуальності даних, офлайн-поведінці.
Проектування Data Access Layer. Інтерфейси, стратегія кешування, offline-політика.
Розробка Sync Engine. SQLite схема, фонова синхронізація, conflict resolution.
Інтеграція з AR Foundation. Прив'язка даних до tracked objects.
Тестування. Сценарії: поганий сигнал, повний офлайн, конфлікти при синхронізації, навантажувальний тест (1000 об'єктів в полі видимості).
| Масштаб інтеграції | Орієнтовні строки |
|---|---|
| Простий REST + кеш (100–500 записів) | 1–2 тижні |
| Офлайн-синхронізація + конфлікти | 3–5 тижнів |
| Real-time WebSocket + складна схема даних | 1–3 місяці |
Вартість розраховується після аналізу структури даних та вимог синхронізації.