Реализация комментариев к элементам (Annotations) в мобильном приложении
Аннотации в мобильном приложении — это не просто чат поверх контента. Это привязка текстового или голосового комментария к конкретной точке на изображении, документе, чертеже или элементе списка. Задача технически интереснее, чем кажется на старте.
Привязка комментария к координатам
Ключевая проблема — нормализация координат. Пользователь тапает на изображение на iPhone SE с одним размером экрана, второй смотрит тот же документ на iPad Pro в landscape. Координата пина должна указывать на одно и то же место.
Решение: храним не абсолютные пиксели, а относительные координаты — x и y как доля от ширины и высоты контейнера (от 0.0 до 1.0). При рендеринге умножаем на актуальный размер контейнера. На iOS это CGPoint(x: pin.relativeX * containerWidth, y: pin.relativeY * containerHeight). На Flutter — аналогично через Positioned внутри Stack с вычисленными left и top.
Для документов с зумом сложнее: нужно учитывать contentOffset и zoomScale у UIScrollView. Сохраняем координату в пространстве контента (content space), а при отображении конвертируем в экранные координаты через UIScrollView.convert(_:to:).
Типичный баг: пины «уезжают» после масштабирования. Происходит потому, что расчёт велся в координатах viewport, а не content. После исправления на content-координаты и добавления scrollViewDidZoom для принудительного обновления позиций — пины встают корректно при любом масштабе.
Хранение и синхронизация
Каждый пин — это объект с полями: id, contentId, relativeX, relativeY, authorId, createdAt, text, resolved. Последнее поле важно: возможность отмечать комментарий как решённый — стандартная фича для review-инструментов.
Для синхронизации между пользователями в реальном времени используем WebSocket (Socket.io или нативный URLSessionWebSocketTask). Новый пин сразу появляется у всех, кто смотрит тот же документ. Оптимистичное обновление: добавляем пин в локальный стейт немедленно, отправляем запрос, при ошибке откатываем.
Для офлайн-сценариев: Core Data или SQLite с флагом pendingSync. При восстановлении соединения батч-синхронизация через REST.
UI компонента пина
Пин на экране — это UIView (или View в SwiftUI / widget в Flutter) с абсолютным позиционированием. Несколько деталей из практики:
Пины не должны вылезать за границы контейнера. При relativeX > 0.95 прижимаем тултип к левому краю, при < 0.05 — к правому. Аналогично по вертикали. Простая логика, но без неё тултип уходит за экран.
Если пинов много (50+), рендерить их все одновременно не стоит. Используем кластеризацию: при мелком масштабе группируем близкие пины в кластер с числом. Раскрываем при зуме. На iOS — MKClusterAnnotation как паттерн (даже если работаем не с картой). На Flutter — ручная кластеризация через quadtree или библиотека flutter_map_marker_cluster.
Тред комментариев
К одному пину может быть несколько ответов — нужен тред. Реализуем через parentId: корневые комментарии имеют parentId: null, ответы ссылаются на родителя. Глубже одного уровня вложенности в мобильном UI не делаем — неудобно.
Компонент треда открывается как bottom sheet (iOS: UISheetPresentationController с .medium и .large detents; Flutter: DraggableScrollableSheet). Это не перекрывает весь экран и не теряет контекст пина.
Что входит в работу
- Компонент пина с нормализованными координатами и поддержкой зума
- Форма добавления и редактирования комментария
- Тред ответов в bottom sheet
- Статус «решено» с визуальным отличием
- REST API интеграция + опциональная WebSocket синхронизация
- Кластеризация пинов при большом количестве
- Поддержка изображений, PDF, произвольных View-контейнеров
Сроки
Базовая реализация (пины на изображении, без треда и синхронизации): 2 дня. Полная версия с тредами, real-time синхронизацией и кластеризацией: 4–5 дней. Стоимость рассчитывается индивидуально после анализа требований и существующего API.