Разработка приложения для инвентаризации со сканированием штрихкодов

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

Мы разрабатываем мобильные приложения для сканирования и инвентаризации, которые заменяют бумажные ведомости и Excel. Наши решения используют камеру смартфона или профессиональные сканеры для чтения штрихкодов, QR-кодов и RFID-меток. В отличие от традиционного подхода, где инвентаризация занимает три дня и чревата ошибками при переносе, автоматизированное приложение позволяет нескольким сотрудникам сканировать одновременно, а данные агрегируются в центральной базе в реальном времени.

Основные проблемы, с которыми сталкиваются компании при внедрении: плохая читаемость кодов в сложных условиях, отсутствие офлайн-режима, сложности интеграции с 1С и SAP. Опыт показывает, что правильный выбор стека (ML Kit, CameraX, Room, WorkManager) и архитектуры (MVVM с Clean Architecture) решает 90% этих проблем. Средняя экономия после внедрения — до 1,5 млн рублей в год для склада с 5000 SKU. Оценим ваш проект — свяжитесь с нами для консультации.

Почему камера смартфона не справляется с чтением кодов на складе?

Самое частое разочарование при первом запуске — камера смартфона плохо читает коды в реальных условиях. ML Kit Barcode Scanning от Google — хороший выбор для Android: поддерживает EAN-13, EAN-8, Code 128, Code 39, QR, DataMatrix, PDF417, Aztec. Но при плохом освещении, бликах на упаковке или повреждённых этикетках распознавание нестабильно. Более подробно — в Google ML Kit Barcode Scanning.

Параметры, которые реально влияют на точность:

• Разрешение превью: CameraX с ResolutionSelector — минимум 1080p для мелких кодов
• BarcodeScanner с включённым ENABLE_ALL_POTENTIALS флагом — агрессивный режим, находит частично перекрытые коды
• Авто-фокус через FocusMeteringAction на центральную зону — без явного запуска иногда не срабатывает на бюджетных устройствах

Для промышленной инвентаризации — Zebra TC21/TC52 или Honeywell CT45. На этих устройствах аппаратный лазерный сканер работает через DataWedge Intent API. Лазерный сканер обрабатывает до 200 кодов в минуту, что в 5–7 раз быстрее камеры смартфона (20–30). На складе это принципиально.

Как работает офлайн-режим в приложении для инвентаризации?

Зоны без Wi-Fi есть на любом складе. Архитектура: Room для локального хранения отсканированных позиций + WorkManager для фоновой синхронизации. Ключевой момент — детектирование конфликтов. Если два сотрудника отсканировали одну и ту же позицию в офлайн, у неё будет два локальных события. На сервере нужна логика дедупликации по document_id + sku + timestamp.

При большой инвентаризации (50 000+ позиций) Room-запросы на выборку с фильтрами нужно покрывать составными индексами. @Index(value = ["sku", "location_code"]) в Entity — иначе поиск по двум полям без индекса работает как full scan.

RFID-инвентаризация

Отдельная история — RFID. Считыватели Zebra RFD40/RFD90 подключаются к смартфону через Zebra RFID SDK (Android). API сессии:

val rfidReader = RFIDReader(activity, readerName, null)
rfidReader.connect()
rfidReader.Events.setInventoryScanEvent(true)
rfidReader.Events.addEventsListener(object : RfidEventsListener {
    override fun eventReadNotify(event: RfidReadEvents) {
        event.ReadEventData.tagData?.forEach { tag ->
            viewModel.onTagRead(tag.tagID, tag.peakRSSI)
        }
    }
    override fun eventStatusNotify(event: RfidStatusEvents) {}
})
rfidReader.Actions.Inventory.perform()

Одна антенна читает до 300 меток в секунду. Погрешность по зоне — плюс-минус 3 метра, что нужно учитывать при инвентаризации по ячейкам хранения. Для склада с 10 000 SKU экономия составляет свыше 3 млн рублей в год.

Как интегрировать сканирование в приложение: пошаговая инструкция

1. Добавьте зависимость в build.gradle: implementation 'com.google.mlkit:barcode-scanning:17.2.0'.
2. Создайте экземпляр BarcodeScanner с опциями: BarcodeScannerOptions.Builder().setBarcodeFormats(Barcode.FORMAT_ALL_FORMATS).enableAllPotentialBarcodes().build().
3. Настройте CameraX с PreviewView и привяжите ImageAnalysis.Analyzer для подачи кадров в сканер.
4. Запустите сканирование и обработайте результат в колбэке: scanner.process(image).addOnSuccessListener { barcodes -> ... }.
5. Для офлайн-режима сохраняйте результаты в Room, а синхронизацию настройте через WorkManager.

Процесс инвентаризации в приложении

Типовой flow: создание документа инвентаризации на сервере → загрузка в приложение → сканирование по зонам → сравнение с учётными данными → фиксация расхождений → отправка результата.

Важная деталь: пересчёт. Когда обнаружено расхождение, кладовщик должен пересканировать зону. Приложение должно позволять редактировать уже занесённые позиции до закрытия документа, но фиксировать все изменения с timestamp и user_id для аудита.

Интеграция с учётными системами

Большинство WMS и ERP предоставляют REST API для документов инвентаризации. 1С — через HTTP-сервисы расширения. SAP — через OData или RFC. Нестандартные системы — через CSV/Excel экспорт по расписанию (медленно, но работает).

Что входит в разработку приложения для сканирования?

• Архитектурная документация и API-спецификация (OpenAPI)
• Исходный код под Android/iOS/Flutter с покрытием unit-тестов
• Настройка CI/CD для App Store и Google Play
• Доступы к сторам и документация по деплою
• Обучение сотрудников работе с приложением
• Техническая поддержка и гарантия 6 месяцев

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

Сроки разработки: приложение под один тип сканирования с REST-интеграцией — 4–7 недель. Полный цикл с RFID, офлайн-режимом, несколькими интеграциями — 2–4 месяца. Стоимость рассчитывается после анализа требований к интеграции и поддерживаемым устройствам. Закажите разработку индивидуального решения — мы подберём оптимальный стек.

Интеграция с железом: BLE, NFC, IoT и HomeKit в мобильных приложениях

Когда задача — связать смартфон с физическим устройством, половина проблем находится не в коде, а в прошивке железа, характеристиках BLE-сервисов и задержках протокола. Мы, как мобильные разработчики, работаем на стыке с firmware-командой, и без понимания стека снизу вверх результат непредсказуем. Вот почему мы всегда начинаем с HCI-лога и спецификации GATT — Apple Developer: Core Bluetooth Framework — это единственный способ избежать реверс-инжиниринга в полевых условиях.

Почему BLE-интеграция — самая частая точка отказа?

Bluetooth Low Energy — основной протокол для носимых, медицинских устройств, умных замков и промышленных датчиков. Core Bluetooth на iOS и BluetoothGatt на Android реализуют одну спецификацию, но ведут себя по-разному в крайних случаях. Статистика наших проектов: более 70% обращений в поддержку по BLE связаны именно с низкоуровневыми ошибками GATT, а не с логикой приложения.

Что делать с ошибкой 133 в Android?

Ошибка 133 — самая частая в Android BLE-разработке. Это не «что-то пошло не так», а конкретный индикатор переполнения очереди GATT или некорректного закрытия предыдущего соединения. Мы лечим её двумя приёмами: используем очередь операций над GATT (write, read, notification subscribe строго последовательно через операционную очередь) и всегда вызываем disconnect() перед close(). Наша очередь GATT-операций в 3 раза снижает количество ошибок ATT_INSUFFICIENT_RESOURCES по сравнению с конкурентными запросами. MTU по умолчанию — 23 байта. Запрос на увеличение (MTU exchange) обязателен для передачи данных объёмом более 20 байт. На iOS MTU запрашивается автоматически при подключении, на Android требуется явно вызывать requestMtu(). Без этого вы не сможете передать, например, изображение или лог через характеристику.

NFC: CoreNFC и Android NFC API

iOS поддерживает NFC-чтение через CoreNFC с версии iOS 11, запись — с iOS 13. Важное ограничение: сессия сканирования активна только пока жив NFCNDEFReaderSession объект и показывает системный UI. Фоновое сканирование доступно только для приложений с entitlement com.apple.developer.nfc.readersession.formats и только для ISO 14443 (банковские карты, паспорта) — и этот entitlement выдаётся не всем. На Android всё проще: NfcAdapter.enableForegroundDispatch() ловит теги в foreground без системного UI. Фоновый запуск приложения по NFC-тегу реализуется через intent-filter с ACTION_NDEF_DISCOVERED. Сравнение платформ по NFC:

HomeKit и Matter

HomeKit — экосистема Apple для умного дома. Для интеграции устройство должно иметь MFi-сертификацию (или работать через Software Authentication для Matter). Мобильное приложение использует HomeKit framework: HMHomeManager → HMHome → HMRoom → HMAccessory → HMService → HMCharacteristic. Matter (ранее CHIP) — кросс-платформенный стандарт, который поддерживают Apple, Google, Amazon и Samsung. На iOS Matter-устройства добавляются через MTRDeviceController, на Android — через Google Home SDK или Matter SDK напрямую. Преимущество Matter: одно устройство работает с HomeKit, Google Home и Alexa без перепрошивки, а конфигурация настраивается в 4 раза быстрее по сравнению с собственным HAP-протоколом.

Для Flutter и React Native используем flutter_blue_plus и react-native-ble-plx соответственно — оба активно поддерживаются и покрывают 90% сценариев, но для работы с GATT-нотификациями в background на Android всё равно нужен foreground service. Убедитесь, что deep linking (Universal Links на iOS, App Links на Android) настроены для корректного пробуждения приложения при сканировании NFC-тега или получении push-уведомления от IoT-устройства. Требования ATT (App Tracking Transparency) для интеграции с железом обычно не применяются, но если приложение собирает анонимную аналитику — добавьте запрос.

Как мы интегрируем BLE и NFC: пошаговый процесс

1. Аналитика — получаем от firmware-команды полную спецификацию BLE GATT (список сервисов, характеристик, форматы данных) или HCI-лог. Без этого разработка превращается в реверс-инжиниринг через nRF Connect или Wireshark over HCI.
2. Проектирование — определяем архитектуру подключений: очередь GATT-операций, фоновые сервисы для Android, переподключение при потере связи. Учитываем MTU-согласование и обработку ошибок ATT_INSUFFICIENT_RESOURCES.
3. Реализация — кодим на Swift/Kotlin с учётом особенностей платформ (Universal Links, App Links, push‑уведомления через APNs/FCM для триггеров). Для защиты Android-кода используем ProGuard / R8 (shrink).
4. Тестирование — на реальных устройствах с первого дня. Эмулятор BLE в симуляторах не воспроизводит edge cases переподключения, потери сигнала, смены MTU. Используем автоматизацию на базе XCTest и Espresso.
5. Деплой — загрузка в App Store Connect / Google Play Console с правильным code signing и provisioning profile. Для iOS — TestFlight, для Android — Firebase App Distribution.

Что входит в работу (deliverables)

• Исходный код мобильного приложения с интеграцией BLE, NFC или IoT (Swift / Kotlin / Flutter / React Native)
• Документация по протоколу GATT (карта сервисов и характеристик)
• Нагрузочное тестирование на 10+ реальных устройствах (ошибка 133, переподключения, MTU-согласование)
• Анализ и устранение edge cases (ошибка ATT_INSUFFICIENT_RESOURCES, потеря соединения на фоне, конфликт с background fetch)
• Инструкция по сборке и деплою (code signing, TestFlight, Firebase App Distribution)
• Месяц поддержки после релиза

Сроки и ориентировочная стоимость

Простая интеграция с одним BLE-периферийным устройством (показания + команды управления) — от 2 до 4 недель. Типичная стоимость такой задачи — от 150 000 до 300 000 ₽, включая отладку GATT-профиля и обработку edge cases. Полноценное IoT-приложение с несколькими типами устройств, firmware OTA-обновлениями и HomeKit-поддержкой — от 2 месяцев. Стоимость рассчитывается индивидуально под ваш проект.

Мы занимаемся мобильной разработкой несколько лет, реализовали 45+ проектов с BLE/NFC/HomeKit. Наши инженеры сертифицированы Apple и Google, а каждый этап работы фиксируется в issue tracker с привязкой к коммитам. Мы используем подход «инженер клиенту»: без маркетинговых пауз, с прямым доступом к разработчику.

Свяжитесь с нами для оценки — получите консультацию инженера с разбором вашей спецификации. Закажите интеграцию под ключ: мы проанализируем HCI-лог, проверим GATT-характеристики и предложим архитектуру за 2 дня.