Ünlem Bilisim : application mobile d'inventaire et de suivi des codes-barres

Faits en bref

• Entreprise : Ünlem Bilişim Teknolojileri A.Ş.
• Rôle : Développeur d'applications mobiles stagiaire
• Période du projet : 2015-2016
• Date de publication de la page : 2024-08-01
• Plateformes : iOS, Android
• Technologie : Delphi RAD Studio, FireMonkey, Object Pascal, SQLite, FireDAC, ZXing
• Limites : utilisation hors ligne, faible capacité de l'appareil, lecture rapide des codes-barres

Cette étude visait à produire une application d'inventaire mobile pouvant être utilisée sur le terrain comme projet final du programme de stage. L'accent était mis sur la distribution iOS/Android avec une base de code unique, un fonctionnement hors ligne et un flux de transactions rapide avec des codes-barres. Le résultat était un produit pilote où les équipes de terrain pouvaient effectuer des transactions de comptage et de débit via des tablettes/téléphones.

Chronologie

• 2015 : Début du stage, recueil des besoins terrain et premier prototype.
• 2016 : Développement d'applications, essais terrain et livraison.
• 01/08/2024 : Date de publication de la page (datePublished).

Problèmes et contraintes

Dans les PME, l'inventaire et la mise à jour des stocks se faisaient sur le terrain avec une faible qualité de connexion. Les systèmes de bureau n'étaient pas portables ; Sur mobile, il fallait concilier lecture de codes-barres, travail hors ligne et accès rapide aux données. La diversité des appareils, la faible luminosité et les ressources matérielles limitées étaient les principales contraintes de la conception. Les pannes de Wi-Fi dans l'entrepôt, l'usure des codes-barres et les caméras de différents appareils ont rendu difficile le fonctionnement stable du produit. De plus, le modèle de données compatible avec les services ERP existants devait être maintenu.

Résumé de la solution

J'ai développé une première application d'inventaire mobile hors ligne pour iOS et Android à partir d'une seule base de code avec Delphi/FireMonkey. La numérisation de codes-barres, le marquage GPS, la base de données SQLite locale et la synchronisation REST se sont réunis pour permettre aux équipes de terrain d'effectuer des opérations rapides et sans erreur. L'application a été conçue pour effectuer toutes les opérations critiques en l'absence de connexion ; Lorsque la connexion est établie, les modifications ont été envoyées de la file d'attente au serveur. Les flux de lecture, de comptage et de débit de codes-barres sont conçus pour être effectués avec un minimum de contact.

L'architecture en un coup d'œil

• Stockage de données hors ligne avec Local SQLite + FireDAC.
• Synchronisation périodique et mises à jour delta avec l'API REST.
• Soumission sécurisée des données avec journal des modifications.
• Politique de conflit simple : victoire de la dernière écriture + contrôle manuel.
• Durabilité de la synchronisation avec réessai/backoff.
• Contrôle de jeton léger pour l'autorisation.

Cette structure visait à rester compatible avec l'enregistrement unique au centre tout en réduisant les pertes de données dans des conditions de faible connexion.

Modèle de données et stratégie de synchronisation

Modèle de données ; Il se composait des tables Produits, Inventaire, Emplacement et TransactionLog. Last_modified et l'ID de l'appareil ont été conservés pour chaque enregistrement ; Ainsi, il a été possible de savoir quels changements provenaient d'où. De plus, les mises à jour en attente étaient mises en file d'attente et envoyées de manière sécurisée avec la table SyncQueue.

La synchronisation s'est déroulée selon un flux push/pull. L'application a d'abord envoyé les modifications accumulées localement au serveur sous forme de petits paquets, puis a extrait du serveur uniquement les enregistrements modifiés. Lorsque le réseau tombe en panne, la file d'attente est préservée et les tentatives sont automatisées.

Principales fonctionnalités

• Recherche et comptage rapides des produits grâce à la lecture des codes-barres (ZXing).
• Vérification de l'inventaire basée sur la localisation avec marquage GPS.
• Fonctionnement hors ligne et synchronisation automatique en matière de réseau.- Interface simple et rapide : listing, détail, comptage, recherche.
• Enregistrements de débits et de mouvements d'entrepôt.
• Recherche/filtre rapide (code-barres, nom, emplacement).
• Accès à l'écran basé sur les rôles et autorisation de base.

Les flux de travail ont été simplifiés grâce à de gros boutons et des formulaires courts, en tenant compte de l'utilisation de gants par le personnel de l'entrepôt.

Compromis d'ingénierie

• La vitesse d'une base de code unique a été équilibrée en limitant certaines optimisations spécifiques à la plate-forme.
• La commodité de la dernière écriture gagnante a créé le besoin d'une approbation manuelle dans les domaines critiques.
• L'approche hors ligne a donné la priorité à la continuité plutôt qu'à la fraîcheur des données.
• L'échantillonnage a été appliqué car la haute résolution réduit la vitesse de lecture des codes-barres.
• La sensibilité du GPS a été équilibrée avec la consommation de la batterie.

Résolution des conflits et intégrité des données

J'ai utilisé une approche de dernière écriture gagnante pour éviter la possibilité que les travailleurs sur le terrain mettent à jour le même produit à des moments différents. Pour les conflits critiques, j'ai donné à l'utilisateur un « avertissement de dernière mise à jour » et ajouté un flux de vérification manuelle. J'ai maintenu l'intégrité des données avec la gestion des transactions SQLite et FireDAC. Pour réduire le taux de chevauchement, j'ai gardé l'intervalle de synchronisation court et envoyé les paquets de modifications par petits lots.

Notes sur les performances

• La charge du processeur a été réduite grâce à l'échantillonnage d'images et à la réduction d'image lors de la lecture de codes-barres.
• La recherche de codes-barres et de noms de produits a été accélérée avec les index SQLite.
• La synchronisation en arrière-plan est conçue pour ne pas bloquer le thread de l'interface utilisateur.
• L'utilisation de la mémoire a été équilibrée avec la pagination sur les écrans de liste.
• Les préférences d'exposition automatiques pour la faible luminosité ont été utilisées dans l'aperçu de l'appareil photo.

Ces optimisations ont permis de garantir que l'application reste fluide, notamment sur les anciens appareils Android. L'objectif principal était d'éviter tout délai entre l'écran de numérisation et l'écran de liste pour un comptage rapide sur le terrain.

Résultats / Impact

• Accélération des processus en utilisation pilote - 20% - durée : 3 semaines pilote - source : retour terrain (rapporté par le client).
• Facilité d'utilisation et accès mobile - amélioration qualitative - source : avis utilisateurs (observés en interne).
• Offre à temps partiel après stage - feedback basé sur les résultats du projet (anecdotique).
• Satisfaction d'utilisation hors ligne - amélioration qualitative - source : notes de terrain (observées en interne).

Leçons apprises

• Architecture hors ligne, la plus grande valeur dans les scénarios de terrain.
• Interface utilisateur simple, essentielle pour les utilisateurs non techniques.
• Les performances sur mobile sont maintenues avec un échantillonnage et une indexation corrects.
• Le contexte de mesure et la tenue de registres sont d'une grande importance dans les projets de stage.
• La stratégie de synchronisation affecte directement la cohérence des données.
• Commentaires réels des utilisateurs, vérification la plus rapide de la conception.

Cette expérience m'a appris à assumer la responsabilité de bout en bout du développement de produits mobiles.

Aperçu du projet

• Entreprise : Ünlem Bilişim Teknolojileri A.Ş.
• Type de projet : Projet final de stage
• Rôle : Développeur d'applications mobiles
• Période du projet : 2015-2016
• Date d'achèvement : août 2016 -Date de la page : 2024-08-01
• Plateforme : iOS, Android
• Technologie : Delphi RAD Studio, FireMonkey, Object Pascal
• Base de données : SQLite + FireDAC
• Intégration : API REST, JSON, ZXing, GPS

##FAQ

Quelles ont été les performances de l'application mobile avec Delphi ?

Les performances étaient adéquates grâce à la compilation native avec FireMonkey ; L'optimisation a été appliquée aux points critiques.

Comment les scénarios hors ligne ont-ils été gérés ?

Une copie locale a été conservée avec SQLite, et la synchronisation a été effectuée via REST à l'arrivée du réseau.

La lecture du code-barres était-elle stable ?

Une lecture stable a été obtenue grâce aux techniques d’échantillonnage ZXing et de réduction de résolution.

Pourquoi Fire

Monkey a-t-il été préféré ?Être publié sur iOS et Android avec une base de code unique et être compatible avec l'écosystème Delphi existant.

Comment les conflits ont-ils été résolus ?

Des gains de dernière écriture ont été mis en œuvre et une vérification a été proposée à l'utilisateur dans des situations critiques.

A quoi servait la balise GPS ?

Pour la vérification de l'emplacement des produits et l'enregistrement en entrepôt lors des opérations sur le terrain.