Розробка мобільного додатка для RFID-інвентаризації

Стандартний штрихкод вимагає прямої видимості та поштучного сканування — це неефективно при масовій інвентаризації. RFID дозволяє зчитати 200 тегів за три секунди, просто пройшовши вздовж стелажа. Ми розробляємо мобільні додатки, які приймають потік EPC-кодів без втрат, дедуплікують їх і звіряють з

Розробка та підтримка будь-яких видів мобільних додатків:

Інформаційні та розважальні мобільні програми
Новинки, ігри, довідники, онлайн-каталоги, погодні, фітнес та здоров'я, туристичні, освітні, соціальні мережі та месенджери, квіз, блоги та подкасти, форуми, агрегатори
Мобільні програми електронної комерції
Інтернет-магазини, B2B-додатки, маркетплейси, онлайн-обмінники, кешбек-сервіси, біржі, дропшиппінг-платформи, програми лояльності, доставка їжі та товарів, платіжні системи
Мобільні програми для управління бізнес-процесами
CRM-системи, ERP-системи, управління проектами, інструменти для команди продажів, облік фінансів, управління виробництвом, логістика та доставка, управління персоналом, системи моніторингу даних
Мобільні програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, платформи надання електронних послуг, платформи кешбеку, відеохостинги, тематичні портали, платформи онлайн-бронювання та запису, платформи онлайн-торгівлі

Це лише деякі з типів мобільних додатків, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 1734 послуг
Розробка мобільного додатка для RFID-інвентаризації
Середній
~5 днів

Наші компетенції:

Часті запитання

Останні роботи

  • image_mobile-applications_feedme_467_0.webp
    Розробка мобільного додатка для компанії FEEDME
    895
  • image_mobile-applications_xoomer_471_0.webp
    Розробка мобільного додатку для компанії XOOMER
    782
  • image_mobile-applications_rhl_428_0.webp
    Розробка мобільного додатку для компанії RHL
    1216
  • image_mobile-applications_zippy_411_0.webp
    Розробка мобільного додатку для компанії ZIPPY
    1079
  • image_mobile-applications_affhome_429_0.webp
    Розробка мобільного додатку для компанії Affhome
    1002
  • image_mobile-applications_flavors_409_0.webp
    Розробка мобільного додатку для компанії FLAVORS
    597

Стандартний штрихкод вимагає прямої видимості та поштучного сканування — це неефективно при масовій інвентаризації. RFID дозволяє зчитати 200 тегів за три секунди, просто пройшовши вздовж стелажа. Ми розробляємо мобільні додатки, які приймають потік EPC-кодів без втрат, дедуплікують їх і звіряють з очікуваним списком — все в реальному часі, навіть без інтернету. Наш досвід — 5 років у мобільній розробці, понад 30 проектів у логістиці та інвентаризації.

Наприклад, на складі з металевими стелажами UHF-теги часто не читаються через відбиття. Ми налаштовуємо параметри зчитувача: потужність, поляризацію, фільтри. В одному проекті вдалося знизити відсоток пропусків з 15% до 2% за рахунок підбору антен і конфігурації. Це особливо важливо для металевих поверхонь, де стандартні налаштування не працюють.

Проблеми, які вирішуємо

Дублікати reads — рідер може зчитати один тег 50+ разів за сесію. Потрібна швидка дедуплікація без блокувань UI. Офлайн-режим — склади часто без Wi-Fi. База даних повинна бути локальною з подальшою синхронізацією. Розбіжності — частина тегів може не читатися через пошкодження або погане розташування. Потрібно явно показувати знайдені, пропущені та зайві позиції. Особливо критично для складів з металевими стелажами, де UHF-теги читаються гірше.

RFID-сканування в 100 разів швидше, ніж ручне введення або штрихкод при перевірці сотень позицій. Але без правильної обробки даних ця перевага втрачається.

Як дедуплікувати EPC-теги без втрат?

Сесія інвентаризації — кінцевий автомат з переходами: IDLE -> SCANNING -> PROCESSING -> COMPLETED, з можливістю паузи. На кожен зчитаний тег — update в MutableStateFlow з дедуплікацією по EPC:

class InventorySession(private val expectedItems: List<InventoryItem>) { private val _scannedEpcs = MutableStateFlow<Set<String>>(emptySet()) val scannedEpcs: StateFlow<Set<String>> = _scannedEpcs.asStateFlow() val matchedItems = scannedEpcs.map { epcs -> expectedItems.filter { it.epc in epcs } }.stateIn(scope, SharingStarted.Eagerly, emptyList()) val missingItems = scannedEpcs.map { epcs -> expectedItems.filter { it.epc !in epcs } }.stateIn(scope, SharingStarted.Eagerly, emptyList()) val unexpectedEpcs = scannedEpcs.map { epcs -> val knownEpcs = expectedItems.map { it.epc }.toSet() epcs.filter { it !in knownEpcs } }.stateIn(scope, SharingStarted.Eagerly, emptyList()) fun onTagRead(epc: String) { _scannedEpcs.update { current -> current + epc } } fun reset() { _scannedEpcs.value = emptySet() } } 

Set<String> — автоматична дедуплікація. Один EPC може прийти 50+ разів, але в Set потрапить один раз. Похідні стейти (знайдені, пропущені, зайві) обчислюються реактивно через map.

Чому офлайн-синхронізація критична для складу?

Ми гарантуємо, що додаток працює без мережі. Локальна БД через Room зберігає очікуваний список і результати:

@Entity(tableName = "inventory_sessions") data class InventorySessionEntity( @PrimaryKey val sessionId: String, val locationId: String, val startedAt: Long, val completedAt: Long?, val status: String // "in_progress", "completed", "synced" ) @Entity(tableName = "scanned_tags") data class ScannedTagEntity( @PrimaryKey val epc: String, val sessionId: String, val firstSeenAt: Long, val readCount: Int ) 

readCount — кількість reads одного тега за сесію. Аномально низька (1–2) при тому що сусідні теги читалися 20+ разів — ознака поганого фізичного розташування тега або пошкодження. Корисна метрика для QA.

Після завершення сесії — синхронізація через WorkManager при появі мережі:

val syncRequest = OneTimeWorkRequestBuilder<InventorySyncWorker>() .setConstraints(Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED).build()) .setInputData(workDataOf("session_id" to sessionId)) .build() workManager.enqueueUniqueWork("sync_$sessionId", ExistingWorkPolicy.KEEP, syncRequest) 

Як відображати результати в реальному часі?

LazyColumn з key(item.epc) — анімоване додавання знайдених позицій:

@Composable fun InventoryResultsScreen(session: InventorySession) { val matched by session.matchedItems.collectAsState() val missing by session.missingItems.collectAsState() val scanned by session.scannedEpcs.collectAsState() Column { LinearProgressIndicator( progress = { if (session.expectedItems.isEmpty()) 0f else matched.size.toFloat() / session.expectedItems.size } ) Text("Знайдено: ${matched.size}/${session.expectedItems.size}") LazyColumn { items(matched, key = { it.epc }) { item -> InventoryItemRow(item = item, status = ItemStatus.FOUND) } items(missing, key = { it.epc }) { item -> InventoryItemRow(item = item, status = ItemStatus.MISSING) } } } } 

GS1 EPC декодування

EPC — це не просто hex-рядок. Структурований код urn:epc:id:sgtin:0614141.107346.2017 містить компанію, артикул та серійний номер. Декодування через SGTIN-96:

Приклад коду декодування SGTIN-96
fun decodeSgtin96(epc: String): Sgtin96? { val bytes = epc.chunked(2).map { it.toInt(16) }.toByteArray() val bits = BigInteger(1, bytes) val header = bits.shiftRight(88).and(BigInteger.valueOf(0xFF)).toInt() if (header != 0x30) return null val filter = bits.shiftRight(85).and(BigInteger.valueOf(0x07)).toInt() val partition = bits.shiftRight(82).and(BigInteger.valueOf(0x07)).toInt() // далі по partition table } 

Готова бібліотека: com.gs4tr.epcis:epcis-rest-client або org.fosstrak.epcis:epcis-repository-client. Детальніше див. GS1 EPC Tag Data Standard.

Порівняння RFID та штрихкодів

Параметр Штрихкод RFID
Швидкість сканування 1 предмет/с 200 тегів за 3 с
Необхідність прямої видимості Так Ні
Перезапис даних Ні Так (деякі теги)
Завадостійкість Висока Середня (метал, рідина)
Вартість мітки 0.01$ 0.05–0.5$

RFID в 10-100 разів швидше при масовому скануванні, але вимагає попереднього налаштування та підбору обладнання.

Порівняння методів декодування EPC

Метод Продуктивність Підтримка GS1 Складність інтеграції
SGTIN-96 вручну Висока (native) Повна Середня
Бібліотека EPCIS Середня (HTTP) Повна Низька
Хмарний сервіс Низька (REST) Частково Мінімальна

Для мобільного додатка оптимальний перший варіант — мінімум залежностей і максимальна швидкість.

Що входить в роботу

  • Проектування архітектури кінцевого автомату інвентаризації
  • Розробка модуля дедуплікації на StateFlow
  • Реалізація офлайн-сховища на Room
  • Налаштування синхронізації через WorkManager
  • Інтеграція з BLE-рідером (Zebra, кастомний)
  • Декодування GS1 EPC та валідація
  • UI на Jetpack Compose з анімованим прогресом
  • Code signing, provisioning, публікація в App Store та Google Play
  • Документація та навчання операторів

Оцініть, як RFID-інвентаризація скоротить час вашого складу — отримайте консультацію наших інженерів.

Процес роботи

  1. Аналітика — вивчаємо процеси складу, типи тегів, WMS.
  2. Прототип — MVP за 3-5 днів з базовим функціоналом.
  3. Розробка — ітеративні спринти по 2 тижні.
  4. QA — навантажувальне тестування з реальним рідером.
  5. Деплой — публікація в сторах і передача.

Терміни

Мобільний додаток інвентаризації з Zebra/кастомним BLE-рідером, офлайн Room, GS1 декодуванням і синхронізацією: від 5 днів (простий склад, один рідер, один тип тегів) до 2–3 тижнів (multi-location, кілька типів тегів, кастомна EPC-схема, REST-інтеграція з WMS).

Зв'яжіться з нами для оцінки вашого проекту — відповімо протягом дня. Замовте консультацію, і ми покажемо, як впровадити RFID-інвентаризацію на вашому складі. Ми гарантуємо проходження App Store Review Guidelines та Google Play політик, а також повну підтримку на всіх етапах.