Ünlem Bilisim: Mobile Inventar- und Barcode-Tracking-Anwendung

Kurze Fakten

• Firma: Ünlem Bilişim Teknolojileri A.Ş.
• Rolle: Praktikant als Entwickler mobiler Anwendungen
• Projektzeitraum: 2015-2016
• Veröffentlichungsdatum der Seite: 01.08.2024
• Plattformen: iOS, Android
• Technologie: Delphi RAD Studio, FireMonkey, Object Pascal, SQLite, FireDAC, ZXing
• Einschränkungen: Offline-Nutzung, geringe Gerätekapazität, schnelles Barcode-Lesen

Ziel dieser Studie war es, eine mobile Inventaranwendung zu erstellen, die als Abschlussprojekt des Praktikumsprogramms vor Ort eingesetzt werden kann. Der Fokus lag auf der iOS/Android-Verteilung mit einer einzigen Codebasis, Offline-Betrieb und schnellem Transaktionsfluss mit Barcodes. Das Ergebnis war ein Pilotprodukt, bei dem Außendienstteams Zähl- und Abbuchungstransaktionen über Tablets/Telefone durchführen konnten.

Zeitleiste

• 2015: Beginn des Praktikums, Erhebung des Feldbedarfs und erster Prototyp.
• 2016: Anwendungsentwicklung, Feldversuche und Lieferung.
• 01.08.2024: Veröffentlichungsdatum der Seite (datePublished).

Probleme und Einschränkungen

In KMU wurden die Bestandszählung und Bestandsaktualisierung vor Ort mit geringer Verbindungsqualität durchgeführt. Desktop-Systeme waren nicht portabel; Auf Mobilgeräten mussten Barcode-Lesung, Offline-Arbeit und schneller Datenzugriff gleichzeitig möglich sein. Gerätevielfalt, schlechtes Licht und begrenzte Hardwareressourcen waren die Haupteinschränkungen des Designs. WLAN-Ausfälle im Lager, Barcode-Verschleiß und unterschiedliche Gerätekameras erschwerten den stabilen Betrieb des Produkts. Darüber hinaus musste das mit den bestehenden ERP-Diensten kompatible Datenmodell beibehalten werden.

Lösungszusammenfassung

Ich habe mit Delphi/FireMonkey eine Offline-First-Mobile-Inventaranwendung für iOS und Android aus einer einzigen Codebasis entwickelt. Barcode-Scanning, GPS-Tagging, lokale SQLite-Datenbank und REST-Synchronisierung sorgten dafür, dass Außendienstteams schnelle und fehlerfreie Einsätze durchführen konnten. Die Anwendung wurde so konzipiert, dass alle kritischen Vorgänge ausgeführt werden, wenn keine Verbindung besteht. Beim Eintreffen der Verbindung wurden die Änderungen aus der Warteschlange an den Server gesendet. Das Scannen, Zählen und Abbuchen von Barcodes ist so konzipiert, dass sie mit minimalem Handgriff erledigt werden können.

Architektur auf einen Blick

• Offline-Datenspeicherung mit Local SQLite + FireDAC.
• Regelmäßige Synchronisierung und Delta-Updates mit REST API.
• Sicherer Datenversand mit Änderungsprotokoll.
• Einfache Konfliktrichtlinie: Last-Write-Wins + manuelle Steuerung.
• Dauerhaftigkeit der Synchronisierung mit Wiederholung/Backoff.
• Leichte Token-Kontrolle für die Autorisierung.

Ziel dieser Struktur war es, mit der Einzelaufzeichnung in der Zentrale kompatibel zu bleiben und gleichzeitig den Datenverlust bei schlechten Verbindungsbedingungen zu reduzieren.

Datenmodell und Synchronisierungsstrategie

Datenmodell; Es bestand aus den Tabellen „Products“, „Inventory“, „Location“ und „TransactionLog“. Last_modified und Geräte-ID wurden für jeden Datensatz gespeichert; So konnte nachvollzogen werden, welche Änderungen woher kamen. Darüber hinaus wurden ausstehende Aktualisierungen in die Warteschlange gestellt und sicher mit der SyncQueue-Tabelle gesendet.

Die Synchronisierung erfolgte mit einem Push/Pull-Ablauf. Die Anwendung sendete zunächst die lokal gesammelten Änderungen in kleinen Paketen an den Server und holte dann nur die geänderten Datensätze vom Server. Wenn das Netzwerk ausfällt, bleibt die Warteschlange erhalten und Wiederholungsversuche werden automatisiert.

Hauptmerkmale

• Schnelles Finden und Zählen von Produkten mit Barcode-Scanning (ZXing).
• Standortbasierte Bestandsüberprüfung mit GPS-Tagging.
• Offline-First-Betrieb und automatische Synchronisierung im Netzwerk.- Einfache und schnelle Benutzeroberfläche: Auflistung, Detail, Zählung, Suche.
• Lastschrift- und Lagerbewegungsaufzeichnungen.
• Schnellsuche/Filter (Barcode, Name, Ort).
• Rollenbasierter Bildschirmzugriff und grundlegende Autorisierung.

Arbeitsabläufe wurden durch große Schaltflächen und kurze Formulare vereinfacht, wobei die Verwendung von Handschuhen durch das Lagerpersonal berücksichtigt wurde.

Technische Kompromisse

– Die Geschwindigkeit einer einzelnen Codebasis wurde durch die Einschränkung einiger plattformspezifischer Optimierungen ausgeglichen.

• Durch die Bequemlichkeit, dass der letzte Schreibvorgang gewinnt, war in kritischen Bereichen eine manuelle Genehmigung erforderlich.
• Beim Offline-First-Ansatz hat die Kontinuität Vorrang vor der Aktualität der Daten.
• Die Abtastung wurde angewendet, da eine hohe Auflösung die Lesegeschwindigkeit des Barcodes verringert.
• Die GPS-Empfindlichkeit wurde an den Batterieverbrauch angepasst.

Konfliktlösung und Datenintegrität

Ich habe einen Last-Write-Win-Ansatz verwendet, um die Möglichkeit zu vermeiden, dass Außendienstmitarbeiter dasselbe Produkt zu unterschiedlichen Zeiten aktualisieren. Bei kritischen Konflikten habe ich dem Benutzer eine „Letzte Update-Warnung“ gegeben und einen manuellen Überprüfungsablauf hinzugefügt. Ich habe die Datenintegrität mit SQLite-Transaktionsmanagement und FireDAC aufrechterhalten. Um die Überlappungsrate zu reduzieren, habe ich das Synchronisierungsintervall kurz gehalten und Änderungspakete in kleinen Stapeln gesendet.

Leistungshinweise

• Die CPU-Last wurde durch Frame-Sampling und Bildreduzierung beim Barcode-Scannen reduziert.
• Die Suche nach Barcodes und Produktnamen wurde mit SQLite-Indizes beschleunigt.
• Die Hintergrundsynchronisierung soll den UI-Thread nicht blockieren.
• Die Speichernutzung wurde durch das Paging auf den Listenbildschirmen ausgeglichen.
• In der Kameravorschau wurden automatische Belichtungseinstellungen für schwaches Licht verwendet.

Diese Optimierungen stellten sicher, dass die App insbesondere auf älteren Android-Geräten flüssig blieb. Das Hauptziel bestand darin, Verzögerungen zwischen dem Scanbildschirm und dem Listenbildschirm zu vermeiden, um eine schnelle Zählung vor Ort zu ermöglichen.

Ergebnisse / Auswirkungen

• Prozessbeschleunigung im Piloteinsatz – 20 % – Zeitraum: 3 Wochen Pilot – Quelle: Feld-Feedback (vom Kunden berichtet).
• Benutzerfreundlichkeit und mobiler Zugriff – qualitative Verbesserung – Quelle: Nutzerbewertungen (intern beobachtet).
• Teilzeitangebot nach dem Praktikum – Feedback basierend auf dem Projektoutput (anekdotisch).
• Offline-Nutzungszufriedenheit – qualitative Verbesserung – Quelle: Feldnotizen (intern beobachtet).

Gelernte Lektionen

• Offline-First-Architektur, der größte Wert in Feldszenarien.
• Einfache Benutzeroberfläche, wichtig für technisch nicht versierte Benutzer.
• Die Leistung auf Mobilgeräten wird durch korrektes Sampling und Indizierung aufrechterhalten.
• Messkontext und Aufzeichnungen sind bei Praktikumsprojekten von großer Bedeutung.
• Die Synchronisierungsstrategie wirkt sich direkt auf die Datenkonsistenz aus.
• Echtes Benutzer-Feedback, schnellste Verifizierung des Designs.

Diese Erfahrung hat mich gelehrt, die End-to-End-Verantwortung für die Entwicklung mobiler Produkte zu übernehmen.

Projektschnappschuss

• Firma: Ünlem Bilişim Teknolojileri A.Ş.
• Projekttyp: Praktikumsabschlussprojekt
• Rolle: Entwickler mobiler Anwendungen
• Projektzeitraum: 2015-2016
• Fertigstellungsdatum: August 2016
• Seitendatum: 01.08.2024
• Plattform: iOS, Android
• Technologie: Delphi RAD Studio, FireMonkey, Object Pascal
• Datenbank: SQLite + FireDAC
• Integration: REST API, JSON, ZXing, GPS

FAQ

Wie war die Leistung der mobilen App mit Delphi?

Dank der nativen Kompilierung mit FireMonkey war die Leistung angemessen; An kritischen Punkten wurde optimiert.

Wie wurden Offline-Szenarien verwaltet?

Eine lokale Kopie wurde mit SQLite aufbewahrt und die Synchronisierung erfolgte über REST, als das Netzwerk ankam.

War das Lesen des Barcodes stabil?

Stabile Messwerte wurden mit ZXing-Sampling- und Auflösungsreduktionstechniken erreicht.

Warum wurde FireMonkey bevorzugt?

Wird mit einer einzigen Codebasis für iOS und Android veröffentlicht und ist mit dem bestehenden Delphi-Ökosystem kompatibel.

Wie wurden Konflikte gelöst?

Es wurden Last-Write-Wins implementiert und dem Benutzer in kritischen Situationen eine Verifizierung angeboten.

Wofür wurde der GPS-Tag verwendet?

Zur Überprüfung des Produktstandorts und zur lagerinternen Aufzeichnung im Feldeinsatz.