Разработка мобильного приложения для управления конференцией – под ключ

Конференция на 2000 участников: расписание меняется каждый час, Wi-Fi падает, а участники одновременно сканируют бейджи на входе. Обычное мобильное приложение здесь не выдержит — нужна архитектура с офлайн-режимом, кэшированием и push-синхронизацией. Мы специализируемся на таких проектах уже 5 лет, реализовали более 30 приложений для мероприятий — от 200 до 5000 участников. За это время выработали проверенные решения, которые экономят до 30% бюджета за счет повторного использования модулей.

Разработка мобильного приложения для управления конференцией: как решаем технические проблемы?

Расписание: как отобразить сотни докладов без лагов?

Расписание конференции — сетка по времени и залам. На iOS: UICollectionView с кастомным UICollectionViewLayout, где каждый доклад — это ячейка с позицией (startTime) и размером (duration). Compositional Layout здесь не подходит — нужна полная кастомизация позиционирования. Кастомный layout с prepare() вычисляет UICollectionViewLayoutAttributes для каждого доклада заранее.

На Android — RecyclerView со стандартным LinearLayoutManager и кастомными ItemDecoration не даст нужного результата. Либо кастомный RecyclerView.LayoutManager, либо Compose Canvas для отрисовки сетки расписания напрямую.

Персональное расписание — пользователь добавляет доклады «в закладки». Хранится локально в UserDefaults / SharedPreferences плюс синхронизируется с аккаунтом. Конфликт расписания (два доклада в одно время) — явное предупреждение при добавлении.

Почему кастомный layout для расписания?

Стандартные компоненты не обеспечивают точного позиционирования ячеек по времени. Кастомный layout даёт полный контроль над визуальным расположением, что критично для сетки с overlapping-докладами и динамическим изменением размеров.

Offline-режим обязателен. Конференционный Wi-Fi часто перегружен. Полное расписание кэшируем при первом запуске, обновляем при наличии сети. URLCache для HTTP-ответов с Cache-Control: max-age=300 на сервере. Докладчики могут опаздывать, залы меняться — обновления приходят через push-уведомление с content-available: 1 (silent push) для инвалидации кэша.

Регистрация: как обработать 5000 участников за час?

QR-код для регистрации участника — зашифрованный ticketId в QR. Волонтёры на входе сканируют через AVMetadataMachineReadableCodeObject (iOS) или ML Kit BarcodeScanning (Android). Валидация в реальном времени через API — ответ за < 500 мс даже при 50 одновременных сканированиях. Ссылки: AVMetadataMachineReadableCodeObject и ML Kit BarcodeScanning — проверенные решения.

Кэш валидированных билетов на устройстве сканера: если API недоступен — проверяем по локальной копии. Риск: кто-то может использовать старый билет повторно. Решение — offline cache только для read, запись в сервер при восстановлении связи.

QR-код участника — генерируем в приложении через CoreImage.CIQRCodeGenerator (iOS) или zxing-android-embedded (Android) из ticketId. Высокий уровень коррекции ошибок (CIQRCodeInputCorrectionLevelH) — QR читается даже с царапиной на экране.

Push и live-обновления: как гарантировать доставку изменений?

Изменения в расписании (перенос доклада, смена зала, отмена) — push в реальном времени. FCM с priority: high для гарантированной доставки. Клиент показывает banner поверх текущего экрана через UIView.animate или snackbar в Compose.

Напоминание за 15 минут до закладок — локальные уведомления через UNUserNotificationCenter. Не Firebase для этого — локальные уведомления работают без интернета. При изменении расписания — перепланируем уведомление: UNUserNotificationCenter.removePendingNotificationRequests(withIdentifiers:) + новый UNNotificationRequest.

Как обеспечить своевременную доставку push?

Комбинация FCM с высоким приоритетом и локальных уведомлений гарантирует, что пользователь получит оповещение даже при слабом интернете. Silent push обновляет кэш без лишних загрузок.

Нетворкинг и взаимодействие

Список участников с фильтром по интересам, компании, роли (докладчик, посетитель, спонсор). Обмен контактами — QR-код профиля или NFC через CoreNFC.NFCNDEFReaderSession (iOS) / NfcAdapter.getDefaultAdapter() (Android). NFC в 2 раза быстрее QR — обмен занимает меньше секунды. NFC для обмена vCard — мгновенно, без камеры.

Чат докладчика с аудиторией — live Q&A. WebSocket канал на доклад, вопросы с upvote. Модератор выбирает вопросы для озвучивания. На сервере: Redis Pub/Sub для broadcast вопросов и голосов всем подключённым клиентам.

Карта конференц-центра

Схема здания — SVG или растровое изображение с наложением интерактивных точек залов. PDFKit (iOS) для векторных планов. Навигация к залу — стрелка с этажом, не полный маршрутный граф (избыточно для одного здания). Indoor Positioning через iBeacon (CLBeaconRegion) для приближения к конкретному залу — опционально, требует наличия beacon-инфраструктуры.

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

• Документация: техническое задание, архитектурная схема, описание API.
• Исходный код: приватный репозиторий с CI/CD, code review.
• Доступы: App Store Connect / Google Play Console, TestFlight, Firebase App Distribution.
• Обучение: инструкция для администраторов конференции, видеотуториалы.
• Поддержка: 2 месяца после релиза — исправление ошибок, адаптация под новые требования.

Процесс и сроки

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

1. Анализ требований: изучаем сценарии использования, нагрузку, интеграции.
2. Проектирование: создаём архитектурную схему, выбираем стек.
3. Реализация: итеративная разработка с демо каждые 2 недели.
4. Тестирование: нагрузочное тестирование симуляцией 5000+ одновременных запросов.
5. Деплой: публикация в App Store и Google Play с поэтапным rollout.

Расписание (сетка + закладки + offline) + push-уведомления + бейджи (QR сканирование) — 6–8 недель. Нетворкинг + чат Q&A + карта + live-обновления — 2–3 месяца. Стоимость рассчитывается после анализа требований. Свяжитесь с нами для предварительной оценки проекта. Получите консультацию — мы подберём оптимальное решение под вашу конференцию.