Реализация Whiteboard (совместная доска) в мобильном приложении

Реализация Whiteboard (совместная доска) в мобильном приложении

При одновременном рисовании нескольких пользователей на одной доске возникают конфликты изменений. Мы решаем эту проблему с помощью CRDT (Conflict-free Replicated Data Types) — синхронизация холста в реальном времени без блокировок. Разрабатываем whiteboard под ключ на Flutter или React Native с нулевой задержкой. Оценим ваш проект за один день.

Совместная доска — бесконечный холст с объектами: линии, фигуры, стикеры, изображения, текст. Пользователи рисуют пальцами или стилусом с поддержкой pressure sensitivity, видят действия друг друга в реальном времени. На мобиле ключевые вызовы — пальцевый ввод, pinch-to-zoom и рендеринг под нагрузкой. Мы гарантируем стабильную работу при 100+ одновременных пользователях.

Архитектура данных: объектная модель холста

Каждый объект на доске — документ в distributed state. Хорошо подходит Y.Map, где ключ — UUID объекта, значение — его свойства (тип, координаты, размер, цвет, z-index). Для составных объектов (путь из точек) — Y.Array точек внутри объекта.

const yobjects = ydoc.getMap('objects');

// Добавляем стрелку
yobjects.set(uuid(), {
  type: 'arrow',
  x1: 100, y1: 200,
  x2: 400, y2: 350,
  strokeColor: '#1a1a2e',
  strokeWidth: 2
});

Конкурентное перемещение одного объекта двумя пользователями: Last-Write-Wins — приемлемо для координат. Конкурентное удаление объекта одним и изменение другим — стандартная проблема CRDT: операция изменения применяется к уже удалённому объекту и теряется. Нужна tombstones-логика или временное хранение «призрачных» объектов.

Рисование кистью: стриминг точек

Свободное рисование (freehand) генерирует 60–120 точек в секунду на 60Hz дисплее. Отправлять каждую точку через WebSocket — избыточно. Оптимизация:

1. Буферизация — отправляем batch точек каждые 50ms.
2. Алгоритм упрощения — Douglas-Peucker убирает избыточные точки с configurable epsilon. Кривая из 500 точек сжимается до 30–50 без видимой потери качества.
3. Stroke prediction — на iOS с Apple Pencil UITouch.predictedTouches предсказывают следующие точки, снижая воспринимаемую задержку.

Stroke как CRDT-объект: начинаем с временного Y.Array точек в Awareness (не в документе — не нужна полная история каждой точки). При завершении (touchEnd) — фиксируем упрощённый путь в документ как единый объект. Это сокращает трафик до 90%.

Как выбрать технологию рендеринга?

Выбор стека рендеринга зависит от платформы и требований к производительности:

React Native: react-native-skia (Skia graphics engine) — лучший вариант для производительного 2D-рендеринга. @shopify/react-native-skia поддерживает Path, Paint, Text, Image. react-native-svg — проще, но медленнее для анимированных объектов.

Flutter: CustomPainter с Canvas API — нативный путь. Для production используем кастомный CustomPainter с dirty-region optimization (перерисовываем только изменившийся регион через Canvas.clipRect).

iOS Native: Metal + MetalKit для максимальной производительности, UIBezierPath + CALayer для среднего уровня сложности. Apple PencilKit — готовый компонент с поддержкой Pencil, но ограниченная кастомизация.

Android Native: Canvas API с Path для простых случаев, OpenGL ES / Vulkan через GLSurfaceView для сложных.

Виртуализация бесконечного холста

При 1000+ объектах рендеринг всего холста в каждом кадре — проблема. Нужен spatial index (R-tree или простой grid-based) для определения объектов в текущем viewport. Рендерим только видимые объекты + небольшой буфер за краями viewport. rbush — JavaScript R-tree библиотека, работает в React Native.

Синхронизация: что отправлять и когда

Cursor/viewport awareness (позиция пользователя на холсте) — через Y.js Awareness, не в документ, 10fps достаточно.

Объекты в процессе создания — два режима:

• Временный preview через Awareness (другие видят незафиксированный объект).
• Только финальный объект после touchEnd (проще, но нет real-time preview рисования).

Первый режим даёт лучший UX, второй — меньше трафика и сложности.

Почему CRDT, а не OT?

CRDT (Yjs) обеспечивает автоматическое разрешение конфликтов без серверного координатора. OT требует центрального сервера для упорядочивания операций, что увеличивает задержку при плохом соединении. CRDT с Yjs в два раза быстрее OT в условиях нестабильной сети, что критично для мобильных приложений. Подробнее о CRDT и Yjs.

Как мы разрабатываем whiteboard: пошагово

1. Анализ требований — определяем стек, прорабатываем объектную модель и сценарии синхронизации.
2. Проектирование архитектуры — схема данных, выбор CRDT-библиотеки (Yjs), настройка WebSocket/WebRTC.
3. Реализация инструментов — кисть, фигуры, текст, изображения с оптимизацией рендеринга.
4. Интеграция синхронизации — подключение Yjs, тестирование конфликтов.
5. Оптимизация производительности — виртуализация холста, сжатие данных (коэффициент до 95% для путей), снижение задержки до 50 мс.
6. Тестирование на реальных устройствах — iOS/Android, разные версии ОС, нагрузка 100+ пользователей.
7. Деплой и поддержка — публикация в App Store/Google Play, документация API.

Типичные ошибки при реализации whiteboard

• Пренебрежение сжатием путей — отправка всех точек приводит к перегрузке канала. Используйте Douglas-Peucker.
• Синхронизация через OT — увеличивает задержку и требует сервер. Выбирайте CRDT.
• Рендеринг всего холста — падение FPS при 500+ объектах. Обязательно внедряйте виртуализацию.
• Игнорирование Apple Pencil prediction — лишняя задержка на iOS.

Этапы и сроки

Базовый whiteboard (фигуры, текст, стрелки, синхронизация) на Flutter или React Native — 10–16 недель. С рисованием кистью, pressure sensitivity, умным упрощением путей и виртуализацией холста — 20–32 недель. Стоимость рассчитывается индивидуально в зависимости от сложности.

Что входит в разработку whiteboard

• Документация архитектуры и API.
• Исходный код в репозитории с CI/CD.
• Интеграция с вашей системой аутентификации (опционально).
• Обучение команды заказчика.
• Гарантийная поддержка 3 месяца.

Свяжитесь с нами для оценки вашего проекта. Мы подберём оптимальный стек и предложим индивидуальные сроки.

Интеграция API в мобильное приложение: с чего начать

Запрос уходит, ответ не приходит, timeout — 30 секунд. Пользователь смотрит на спиннер. Сети нет — мобильная карта в метро. Или сеть есть, но сервер вернул 200 с HTML-страницей ошибки вместо JSON — и приложение крашит при JSONDecoder.decode(). Мы видим такие кейсы на каждом втором проекте. Поэтому интеграция API в мобильное приложение — это не просто вызов endpoint'а, а проектирование надёжного сетевого слоя: обработка ошибок, кэширование, offline-режим, certificate pinning. Закажите аудит текущего сетевого слоя — оценим проект за 1 день.

Почему стандартные библиотеки недостаточны? URLSession и OkHttp предоставляют базовый HTTP-клиент, но для production нужны retry с exponential backoff, валидация статус-кодов, типизированная десериализация и мониторинг состояния сети. Без этого приложение теряет данные и пользователей. Мы уже 5 лет занимаемся мобильной разработкой и реализовали более 30 проектов с интеграцией API на iOS, Android и Flutter — от стартапов до enterprise-решений.

Как выбрать протокол для интеграции API?

REST остаётся стандартом для большинства проектов. Но когда на экране профиля нужно 5 полей из 40, GraphQL исключает over-fetching и сокращает трафик на 30–60%. gRPC оправдан при тысячах запросов в минуту (trading, IoT) — бинарная сериализация в 3–5 раз быстрее JSON. WebSocket — единственный выбор для real-time без polling (сообщения, уведомления).

Пример из практики: для финтех-приложения мы заменили REST (40 полей) на GraphQL — размер ответа сократился с 12 КБ до 2,5 КБ, время рендера экрана упало на 70%. Экономия трафика составила около 15 000 ₽ в месяц при 100 000 активных пользователей.

Как обеспечить надёжность соединения и offline-first

Пользователи теряют сеть в метро, лифте, тоннеле. Мобильное приложение обязано работать без интернета — хотя бы в read-only режиме. Мы внедряем паттерн offline-first:

1. При открытии экрана сначала показываем данные из локального кеша (Core Data / Room).
2. Параллельно выполняем сетевой запрос, обновляем UI после ответа.
3. Если сеть недоступна — показываем кешированные данные и метку «нет соединения».
4. При восстановлении сети автоматически синхронизируем изменения.

Для кэширования HTTP-ответов используем URLCache (iOS) и OkHttp Cache (Android) с поддержкой Cache-Control. Для структурированных данных — SwiftData / Room. NWPathMonitor / ConnectivityManager.NetworkCallback отслеживают состояние сети и триггерят обновление.

REST и выбор клиентской библиотеки

Alamofire (iOS) — де-факто стандарт для Swift-проектов. Поверх URLSession добавляет request chaining, response validation, automatic retry, certificate pinning через ServerTrustManager. AF.request() с .validate() возвращает ошибку для любого статус-кода вне 200–299. Без .validate() Alamofire считает 404 и 500 успешными ответами. С Swift Concurrency — async-версия через serializingDecodable.

Retrofit (Android) — аннотационный HTTP-клиент поверх OkHttp. Интерфейс с аннотациями компилируется в реализацию. @GET, @POST, @Path, @Query, @Body — декларативное описание API. OkHttp под капотом: connection pooling, transparent gzip, HTTP/2 multiplex. HttpLoggingInterceptor — логирование в debug-сборке. Authenticator — автоматический refresh токена при 401.

Ktor (KMM/Flutter) — мультиплатформенный HTTP-клиент. На iOS работает через Darwin engine (URLSession), на Android — через OkHttp. Единый код для обеих платформ при KMM-архитектуре.

GraphQL: когда REST не справляется

REST возвращает фиксированную структуру. Экран профиля требует name, avatar, email — сервер отдаёт 40 полей. Over-fetching. GraphQL решает это: клиент запрашивает ровно нужные поля. Это критично для мобайла, где трафик и время парсинга — реальные ограничения. Apollo iOS и Apollo Kotlin генерируют типизированные классы по схеме: schema.graphql + query-файлы → строгие типы на этапе компиляции. Subscriptions через WebSocket — real-time без polling. Ограничение: GraphQL сложнее кешировать на уровне HTTP. Apollo использует нормализованный in-memory кеш InMemoryNormalizedCache — запросы с пересекающимися данными обновляют кеш без дублирования. Apollo GraphQL Documentation

WebSocket: real-time без лишнего трафика

Polling (setInterval каждые 5 секунд) — трата батареи и трафика. WebSocket — постоянное двунаправленное соединение. iOS: URLSessionWebSocketTask (нативный, iOS 13+). Android: OkHttp WebSocket. Обязательная обработка reconnect: при onFailure — экспоненциальный backoff (1с → 2с → 4с → 8с → максимум 60с). Socket.IO — надстройка с автоматическим reconnect, но для новых проектов предпочтительнее нативный WebSocket (меньше зависимостей).

gRPC: для высоконагруженных сервисов

gRPC с protobuf — бинарная сериализация: меньше размер, быстрее парсинг. grpc-swift для iOS, grpc-kotlin для Android. Protobuf-схема компилируется в типизированные классы. Streaming (server-side, client-side, bidirectional) — нативная возможность. Порог применения: высокая частота запросов (trading, IoT) или критичная latency. Для обычного CRUD REST проще в дебаге и мониторинге.

Certificate Pinning и безопасность

Корпоративный proxy может перехватить HTTPS через подмену сертификата. Certificate pinning предотвращает это: приложение принимает только конкретный сертификат или публичный ключ. Alamofire: ServerTrustManager с PinnedCertificatesTrustEvaluator. OkHttp: CertificatePinner с SHA-256 хешем. Операционная сложность: при ротации сертификата старые версии приложения перестают работать. Решение — pinning на публичный ключ CA или поддержка нескольких пинов с grace period. Подробнее о certificate pinning на Wikipedia

Что входит в работу

Мы передаём: исходный код сетевого слоя, документацию по используемым библиотекам, инструкцию по ротации сертификатов, поддержку в течение 2 недель после сдачи.

Сроки и стоимость

Реализация сетевого слоя с REST, retry, кэшированием и offline-режимом — 1–2 недели. Добавление GraphQL или WebSocket — ещё 1–2 недели. gRPC — 2–3 недели, включая кодогенерацию. Стоимость рассчитывается индивидуально после анализа API и требований к offline-поведению. Оценим проект за 1 день — свяжитесь для консультации.