RFID auf Android-Handhelds: Was das SDK Ihnen nicht sagt

Jeder RFID-Anbieter liefert eine Demo-App, die in neunzig Sekunden ein Etikett liest. Jedes Deployment verbringt danach drei Monate damit herauszufinden, dass diese Demo keine der Fragen beantwortet hat, die um vier Uhr nachmittags im Lager zählen: warum der Auslöser nicht mehr reagiert, warum der Akku in der sechsten Stunde stirbt, warum die Liste so langsam scrollt, dass die Bediener ihr nicht mehr trauen.

Dieser Artikel handelt von der Lücke zwischen diesen beiden Apps. Das SDK ist ein kleiner Teil davon.

Die SDK-Landschaft: was Sie tatsächlich integrieren

Drei APIs, drei verschiedene Designannahmen, und sie zu vermengen ist der erste Fehler.

• Das RFID-SDK ist eine in Java gekapselte native Bibliothek: Es besitzt eine Antenne, einen Leser-Thread und eine Callback-Schnittstelle.
• Die Barcode-API (DataWedge oder EMDK) ist ein separates Subsystem mit eigenen Lebenszyklusregeln, auch auf demselben Gerät.
• Barcode- und RFID-Ereignisse kommen über verschiedene Callbacks und müssen zu einem Scanmodell zusammengeführt werden, bevor die UI etwas sieht.
• Hersteller-SDKs unterscheiden sich in ihren Thread-Garantien; steht in der Dokumentation nichts über Thread-Sicherheit, nehmen Sie an, dass es keine gibt.
• Fixieren Sie die SDK-Version pro Gerätemodell und behandeln Sie Upgrades als Release, weil sich das Verhalten zwischen Minor-Versionen ändert.

Threads, Callbacks und der Auslöser

Der Auslöser ist das meistberührte Teil der App und die häufigste Quelle für „es funktioniert nicht mehr".

• Leser-Callbacks kommen auf einem SDK-Thread; berühren Sie dort niemals UI oder Datenbank, übergeben Sie die Arbeit an eine Queue.
• Ein Auslöserdruck startet eine Lesesitzung, das Loslassen beendet sie; machen Sie beides idempotent, weil Hardware-Ereignisse sich duplizieren.
• Wird eine Sitzung gestartet, während eine läuft, öffnen Sie keine zweite; koaleszieren Sie, sonst meldet der Leser Fehler, die Sie wochenlang verfolgen.
• Jede Sitzung braucht einen Watchdog: Kommt in N Sekunden kein Ereignis, bauen Sie den Leser ab und neu auf, statt ewig zu warten.
• Initialisieren Sie nach jedem App-Resume neu, weil der Leserzustand weder Prozessende noch Neustart überlebt.

Lesekonfiguration ist nicht die eines Festlesers

Handheld-Standardwerte sind für eine Demo auf dem Schreibtisch abgestimmt, und ein Lager ist kein Schreibtisch.

• Die Sendeleistung sollte dem Workflow folgen: niedrig für Regalgenauigkeit, hoch für ein hohes Regal, niemals Maximum als Standard.
• Die Sitzungswahl zählt mehr als an einem Portal: Sitzung eins hält Etiketten zwischen Lesungen ruhig, was zum wiederholten Zählen desselben Regals passt.
• Filtern nach EPC-Präfix vor der Singulation ist der billigste Weg, den Bestand des Nachbargangs nicht mehr zu lesen.
• Ein kurzes Deduplizierungsfenster in der App ist normal; ein langes verdeckt echte Duplikate.
• Der Batch-Modus verbessert den Durchsatz, verzögert aber das erste Ergebnis; die UI muss zeigen, dass gelesen wird, sonst drücken Bediener fester.

Oberflächengestaltung für das Massenlesen

Ein Massenlese-Bildschirm ist keine Liste, sondern eine Fortschrittsanzeige mit Ausnahmen.

• Zeigen Sie einen laufenden Zähler als Hauptzahl, keine scrollende Liste; der Zähler ist, was der Bediener feststellen will.
• Zeigen Sie die letzten Lesungen für Vertrauen, begrenzen Sie aber die sichtbaren Zeilen, denn eine Liste mit tausend Zeilen ist ein eingefrorener Bildschirm.
• Unterscheiden Sie drei Zustände visuell: lesend, inaktiv und Störung; Bediener diagnostizieren über Farbe lange bevor sie eine Meldung lesen.
• Stellen Sie die Ausnahme nach vorn: unbekanntes Etikett, falscher Standort, bereits gezählt, damit der Bediener im Moment des Scans handeln kann.
• Auslöser und Bildschirmtaste müssen dasselbe tun, weil Handschuhe und Sonnenlicht jede Annahme über Berührung brechen.

Erst offline, dann synchronisieren

Lager haben Funklöcher, und eine Zählung, die nicht gespeichert werden kann, wird wiederholt.

• Speichern Sie jede Lesung zuerst lokal, in einem sitzungsbezogenen Store, und synchronisieren Sie danach; blockieren Sie die Scanschleife nie mit einem Netzaufruf.
• Machen Sie die Synchronisierungseinheit die Sitzung, nicht das Etikett, damit ein Teil-Upload ohne Duplikate fortgesetzt werden kann.
• Nutzen Sie eine monotone lokale Sequenznummer und eine Gerätekennung für Idempotenz auf dem Server.
• Zeigen Sie den Sync-Zustand explizit: ausstehend, laufend, fehlgeschlagen mit Wiederholungszähler, damit niemand ein grünes Häkchen annimmt, das nie kam.
• Lösen Sie Konflikte auf dem Server mit einer Regel, die das Feldteam kennt, statt Last-Write-Wins auf dem Gerät.

Akku, Wärme und die Realität einer achtstündigen Schicht

RFID ist eine stromhungrige Funktion, und sie kommt meist zu einer App, die schon knapp war.

• Dauerhaftes Lesen mit hoher Leistung kann die Akkulaufzeit halbieren; budgetieren Sie die Schicht, nicht die Demo.
• Halten Sie den Leser nur während einer Sitzung unter Strom und geben Sie ihn im Leerlauf frei, denn eine aktive Antenne zieht auch, wenn niemand scannt.
• Beobachten Sie die Wärme: Dauerlesen auf einem warmen Gerät löst Throttling aus, das wie ein Reichweitenproblem aussieht.
• Deaktivieren Sie Hintergrundortung und nicht benötigte Funkmodule; das RFID-Modul ist nicht der einzige Verbraucher in der App.
• Geben Sie dem Bediener eine sichtbare Akkuschwelle und eine frühe Warnung, damit eine Zählung nicht bei neunzig Prozent verloren geht.

Flottenverwaltung: eine App, viele Geräte

Eine Handheld-Flotte driftet, und die Drift ist unsichtbar, bis ein Standort andere Zahlen meldet.

• Fixieren Sie App-Version, SDK-Version und Konfigurationsprofil pro Gerätemodell und protokollieren Sie sie im Scan-Payload.
• Senden Sie die Konfiguration vom Server, nicht aus einem Einstellungsbildschirm, damit eine falsch gesetzte Leistungsstufe nicht monatelang bleibt.
• Nutzen Sie ein MDM, um Updates zu verteilen und zu verhindern, dass Bediener „zum Testen" eine andere Version installieren.
• Protokollieren Sie die Geräteidentität bei jeder Sitzung; sehen die Zahlen eines Standorts seltsam aus, ist die erste Frage, welcher Build lief.
• Mustern Sie Geräte explizit aus und widerrufen Sie ihre Zugangsdaten, damit ein verlorenes Handheld nicht weiter Inventar schreibt.

Auf echten Regalen testen, nicht am Schreibtisch

Die Demo besteht auf dem Schreibtisch. Das Release muss auf einem Metallregal mit hundert Kleidungsstücken bestehen.

• Testen Sie mit dem echten Etikett und der echten Anbringung, denn ein gefaltetes Webetikett liest sich anders als ein flacher Inlay.
• Testen Sie am schlechtesten Ort des Gebäudes: die entfernte Ecke, das Metallregal, der Gang neben dem Tor.
• Testen Sie die ganze Schicht: Start mit niedrigem Akku, zwei Stunden lesen, App in den Hintergrund, zurückkehren und prüfen, ob die Sitzung überlebt hat.
• Testen Sie mit Handschuhen und in der Sonne, weil beides ändert, wie Auslöser und Bildschirm tatsächlich benutzt werden.
• Halten Sie eine Regressionszählung eines bekannten Regals: gleiches Regal, gleiche erwartete Zahl, vor jedem Release.

Das Muster dahinter ist unspektakulär: Behandeln Sie den Leser als unzuverlässige Peripherie, das Netz als abwesend, den Akku als endlich und den Bediener als jemanden mit Handschuhen in schlechtem Licht. Apps, die auf diesen Annahmen gebaut sind, überleben den ersten Montag; Apps, die auf der Demo gebaut sind, nicht.