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

Стандартний штрихкод вимагає прямої видимості та поштучного сканування — це неефективно при масовій інвентаризації. 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:

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
}