Разработка мобильного приложения для охранного предприятия
Приложение для охранного предприятия — это не просто CRM с нарядами. Это система, где задержка push-уведомления на 30 секунд может означать реальный инцидент без реакции. Надёжность доставки сигналов тревоги и геолокационный контроль нарядов — вот что определяет архитектурные решения.
Три контура системы
Приложение охранного предприятия как правило обслуживает три группы пользователей с разными потребностями:
Клиент (заказчик охраны): запрос на вызов охраны, статус объекта (охраняется/снят), история тревог, документы (акты, договоры), личный кабинет с контактами группы быстрого реагирования.
Охранник на объекте: чек-лист обхода с геолокационными точками, фиксация событий (начало/конец смены, обход выполнен, инцидент), тревожная кнопка, связь с диспетчером, навигация к объекту.
Диспетчер: карта с текущими нарядами в реальном времени, входящие тревоги, распределение нарядов, журнал событий.
Это три отдельных интерфейса — но один бэкенд и, при желании, одно Flutter-приложение с переключением профиля.
Геолокация и мониторинг нарядов — технически самое сложное
Охранник на объекте должен периодически подтверждать своё присутствие в назначенной геозоне. Реализуем через фоновую геолокацию: flutter_background_geolocation (коммерческий плагин, но единственный надёжный для iOS + Android с фоновым режимом) или geolocator в связке с foreground service.
На Android без foreground service с постоянным уведомлением фоновая геолокация убивается Doze Mode примерно на третьем часу смены — особенно на Xiaomi и Huawei с агрессивными политиками энергосбережения. Это не теоретический риск: мы с этим столкнулись при разработке приложения для охраны торговых центров. Решение — foreground service + wake lock + белый список в настройках батареи (с онбордингом, который объясняет пользователю, что нужно сделать).
Данные геолокации охранника пишутся в PostGIS (PostgreSQL) — это позволяет строить отчёты по траектории смены, верифицировать факт обхода точек маршрута через ST_DWithin.
Точки обхода — это геозоны на карте объекта. При подходе охранника на 10 метров — автоматическая отметка. Можно добавить NFC-метку на физической точке для дополнительного подтверждения (через flutter_nfc_kit).
Тревожная кнопка
Тревога от охранника должна дойти до диспетчера максимально быстро. WebSocket (Laravel Broadcasting + Pusher или собственный Socket.io) — задержка 100-300 мс в нормальных условиях. Push через FCM — резервный канал, но FCM не гарантирует доставку в секунды.
Для клиентского тревожного сигнала (паника-кнопка на объекте) — то же самое, плюс автоматическое создание наряда на ближайшую свободную группу реагирования.
Интеграции
- Интеграция с системами сигнализации (Bolid, С2000) через API охранного пульта — если ЧОП хочет видеть в приложении статус датчиков
- Телефония через SIP (linphone_sdk) — для связи диспетчера с охранником без выхода из приложения
- Генерация актов и нарядов в PDF по шаблону
Стек
Flutter 3.x + Clean Architecture (feature-first), Laravel 10 + WebSocket, PostgreSQL + PostGIS, FCM, Redis для real-time данных.
Этапы и сроки
Аналитика → проектирование трёх ролевых интерфейсов → UX/UI → разработка → стресс-тестирование геолокационных сценариев → публикация → поддержка.
MVP с геомониторингом нарядов, тревожной кнопкой и клиентским приложением — от 18 до 24 недель. Полная система с интеграцией сигнализации, SIP-телефонией и расширенной аналитикой — от 32 недель.
Стоимость рассчитывается индивидуально после анализа требований.