Стандартний штрихкод вимагає прямої видимості та поштучного сканування — це неефективно при масовій інвентаризації. 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-інвентаризація скоротить час вашого складу — отримайте консультацію наших інженерів.
Процес роботи
- Аналітика — вивчаємо процеси складу, типи тегів, WMS.
- Прототип — MVP за 3-5 днів з базовим функціоналом.
- Розробка — ітеративні спринти по 2 тижні.
- QA — навантажувальне тестування з реальним рідером.
- Деплой — публікація в сторах і передача.
Терміни
Мобільний додаток інвентаризації з Zebra/кастомним BLE-рідером, офлайн Room, GS1 декодуванням і синхронізацією: від 5 днів (простий склад, один рідер, один тип тегів) до 2–3 тижнів (multi-location, кілька типів тегів, кастомна EPC-схема, REST-інтеграція з WMS).
Зв'яжіться з нами для оцінки вашого проекту — відповімо протягом дня. Замовте консультацію, і ми покажемо, як впровадити RFID-інвентаризацію на вашому складі. Ми гарантуємо проходження App Store Review Guidelines та Google Play політик, а також повну підтримку на всіх етапах.