Сканер штрихкодов в приложении проверяют на камере телефона и повреждённых этикетках

Слово «штрихкод» не задаёт требования к сканеру. Исполнитель должен получить образцы каждого нужного формата с известным содержимым.

Google ML Kit поддерживает EAN-13, Code 128 и Data Matrix; документация проверена 08.10.2026. Наличие формата в списке SDK ещё не подтверждает чтение вашей этикетки.

Постановка задачи агенту начинается с ожидаемого результата. Для сканера это строка кода и действие приложения, например открытие нужной карточки товара.

Тест на сохранённой картинке проверяет декодер. Он не показывает, как камера сфокусируется на упаковке под светом магазина.

Google связывает чтение с фокусом и размером кода в кадре. GS1 отдельно требует свободное поле вокруг кода; залом или соседняя надпись могут нарушить условия чтения.

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

Отсутствие результата распознавания ничего не говорит о наличии товара. Камера могла не получить доступ, а декодер мог не прочитать этикетку.

Даже прочитанная строка требует проверки приложением. Ведущие нули сохраняют в исходном значении, а преобразование в формат каталога задают явно: у GS1 представление GTIN использует такие нули.

Ручной ввод проходит ту же проверку формата и поиск. Если поиск не ответил, сотрудник должен увидеть ошибку связи, а не сообщение «товар не найден».

Последовательность кадров проверяют как одно сканирование. Повторные результаты одного кода не должны запускать действие приложения заново до завершения текущей операции.

Неудобный вход должен стать отдельным образцом проверки. В машине vibecoding.ru инженер ведёт агентов по правилам, которые пополняются после сбоев.

Для сканера полезна граница между неизвестным результатом и подтверждённым отсутствием. Её нельзя закрыть общим сообщением «ничего нет».

Правила для агентов сохраняют такую границу между задачами. Ниже наши случаи с веб-данными; перенос на мобильное приложение является предложением приёмки.

Агент может собрать экран камеры, обработку разрешения и тесты на сохранённых изображениях. Проверка физической камеры остаётся за человеком с нужным телефоном и этикеткой.

Проверка ошибок агента требует отдельной приёмки результата. Автор правки не подтверждает её своим сообщением «готово».

Протокол связывает дефект с версией сборки и образцом. После исправления повторяют тот же сценарий и добавляют его к проверкам следующих выпусков.

Заказ стоит ограничить действием внутри приложения. Сканер открывает карточку товара; оформление продажи или проверка маркировки получают отдельные требования.

На странице разработки по подписке тариф «Один проект» стоит 250 000 ₽ в месяц на 08.10.2026. Это один продукт и один поток работы, а не смета сканера.

Сроки разработки включают ожидание проверки. Доступ к сборке, телефонам и образцам этикеток стоит подготовить до начала интеграции.

Первой задачей в подписке может стать встроенный сканер с оговорёнными форматами, разрешением камеры и ручным вводом. Отдельную лицензию коммерческого SDK обсуждают до выбора библиотеки.

Перед заказом можно обсудить приёмку сканера. Для разговора нужны перечень телефонов и образцы этикеток с ожидаемыми значениями.

Разовую доработку без дальнейшего потока задач сравнивают с разовым заказом. Подписку оценивают по очереди изменений приложения, а не по цене готовой программы из магазина.

1. Укажите форматы и ожидаемые значения до выбора библиотеки.

2. Принимайте камеру на телефонах сотрудников и этикетках компании.

3. Разделите непрочитанный код, отсутствие товара и ошибку поиска.

4. Проверьте ручной ввод как часть того же действия.

5. Сохраните каждый дефект как образец для повторной приёмки.