id: 233 slug: ar-external-database-integration-module-development title_en: "Development of External Database Integration Modules for AR" tags: [vr-ar]
Development of External Database Integration Modules for AR
AR-app for warehouse accounting shows employee product info directly over physical box. Data pulled from ERP in real-time. Request delay 800 ms — and annotation appears after employee already looked away. This is not UX-nuance — direct scenario failure. AR integration with external databases requires different approach to query architecture than typical mobile apps.
Key Technical Challenges
Query latency in AR more critical than any mobile context. User points camera at object and expects instant response. 300 ms — acceptable, 800 ms — noticeable delay, 2 seconds — app seems broken.
Main delay sources:
- Network round-trip to server (100–300 ms in 4G/5G, 20–50 ms in WiFi)
- Server query processing time (SQL-query without index on 5-million-row table — easily 500 ms)
- JSON deserialization on client
Solution — predictive loading and caching. In warehouse AR-app when pointing at shelf we know next 30 seconds user works with this zone. Prefetch requests data for all zone articles in single batch-request immediately on shelf marker recognition, places in local cache. When user points at specific box — data ready.
Offline mode — second critical moment. In warehouses, industrial shops, medical facilities with metal partitions, signal unstable. AR-app must work with cached data and synchronize changes on connection recovery. Merge conflicts (user changed quantity in AR, other user changed same field in ERP) — handled via timestamps + last-write-wins or explicit conflict resolution UI.
Integration Module Architecture
Build on three layers:
Data Access Layer — abstraction over data source. IProductRepository with methods GetByBarcode(string code), GetByZone(string zoneId), UpdateQuantity(string id, int delta). Concrete implementation can be REST, GraphQL, gRPC or direct SQLite — AR-logic layer doesn't know.
Sync Engine — cache and synchronization management. SQLite via sqlite-net-pcl on device as local storage. Background SyncWorker polls server every N seconds (configurable) or reacts to push via WebSocket/SignalR. Caching strategy — TTL per entity type: fast-changing data (warehouse quantity) — 30 seconds, references (names, characteristics) — 24 hours.
AR Binding Layer — data connection to AR-objects. In AR Foundation: on ARTrackedObjectsChangedEventArgs.added — request data for recognized object via IProductRepository, populate ARAnnotationController with received data. On removed — hide annotation, cancel pending requests via CancellationToken.
For performance use UniTask (or ValueTask in standard .NET) instead of standard coroutines — less allocations, native task cancellation via CancellationToken, proper exception handling in async/await.
Typical AR-Project Integrations
REST API (most common): HttpClient with System.Net.Http, Newtonsoft.Json or System.Text.Json for deserialization. Important: HttpClient must be singleton or pooled — each new HttpClient() opens new socket pool.
GraphQL: particularly convenient for AR-apps — request only needed fields, get related data in one query. graphql-net-client or Strawberry Shake for .NET.
WebSocket / SignalR: for real-time updates — e.g. AR-annotations on production line where equipment status changes every seconds. SignalR Core on backend, Microsoft.AspNetCore.SignalR.Client on client.
Direct database connection in AR-apps not recommended — anti-pattern from security (DB credentials in APK) and scalability perspective.
Work Stages
Data source analysis. Study API or database structure, determine data actuality requirements, offline behavior.
Data Access Layer design. Interfaces, caching strategy, offline-policy.
Sync Engine development. SQLite schema, background synchronization, conflict resolution.
AR Foundation integration. Data binding to tracked objects.
Testing. Scenarios: poor signal, full offline, conflicts on synchronization, load test (1000 objects in view).
| Integration Scale | Estimated Timeline |
|---|---|
| Simple REST + cache (100–500 records) | 1–2 weeks |
| Offline-synchronization + conflicts | 3–5 weeks |
| Real-time WebSocket + complex schema | 1–3 months |
Cost calculated after data structure and synchronization requirements analysis.