Enioka Scan est une bibliothèque Android open-source qui simplifie l’intégration des scanners de code-barre dans son application.
Les scanners de code-barre souffrent d’un problème répandu : en plus de la base commune, chacun ajoute des fonctionnalités propres et chaque constructeur propose son propre SDK, souvent propriétaire et/ou mal documenté. Pire, il arrive que le constructeur sorte sa propre application sans possibilité de customisation. Avec toutes ces spécificités qui limitent ou interdisent la compatibilité logicielle voire matérielle, il devient donc difficile de changer de constructeur voire de modèle, et impossible de faire cohabiter simplement des scanners de marques différentes au sein d’une même application.
Enioka Scan propose une abstraction aux SDKs propres à chaque scanner et expose une unique API comportant les fonctionnalités les plus utilisées (lecture de code barre, illumination, signaux sonores, etc.) : il n’y a besoin de maintenir qu’une seule application quel que soit le constructeur, et il devient enfin possible de choisir librement son fournisseur sans contrainte de compatibilité. Certains scanners nécessitent encore un SDK propriétaire afin d’être compatibles, mais la majorité fonctionne grâce à un driver open-source inclus dans la bibliothèque.
La bibliothèque vient de sortir sa version 2.0.0, apportant d’importants changements dans les APIs exposées, rendant son utilisation plus intuitive et ses fonctionnalités plus complètes. De nouveaux scanners sont également supportés (Athesi E5L et Honeywell EDA52), et de nombreux bugs ont été corrigés.
Liens:
- Github: https://github.com/enioka/enioka_scan
- Release 2.0.0: https://github.com/enioka/enioka_scan/releases/tag/2.0.0
# Android ?
Posté par claudex . Évalué à 5.
Alors, je ne connais pas du tout le monde des scanners de code-barre. Du coup, je me pose la question, est-ce si répandu de le connecter à un android plutôt qu'à un Linux/Windows classique ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Android ?
Posté par Watchwolf . Évalué à 3.
J'imagine par exemple des caisses enregistreuse basés sur Android ?
[^] # Re: Android ?
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 5.
J'ai vu un certain nombre de tablettes en effet faire office de caisse enregistreuse.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Android ?
Posté par raphj . Évalué à 10. Dernière modification le 21 mai 2022 à 08:49.
En fait, il arrive que le scanner de codes barres soit dans l'appareil Android lui-même. Cet appareil a la forme et d'ailleurs (toutes) les fonctionnalités d'un téléphone, mais est généralement présenté comme un ordinateur mobile. On peut y mettre une carte SIM et téléphoner ou envoyer des SMS. C'est par exemple certainement le cas du Honeywell EDA52 mentionné dans le journal. J'ai eu l'occasion de travailler sur le modèle précédent (l'EDA51), ainsi que sur un téléphone Zebra. C'est vraiment de l'Android tout ce qu'il y a de plus classique, avec un lecteur de codes barres intégré et des boutons latéraux pour déclencher le lecteur de codes barres. Ce lecteur prend en charge plusieurs formats de codes barres, y compris les QR Codes. La batterie est assez impressionnante, ça tient longtemps, et la construction est solide, on sent que le matériel est de bonne qualité (dans les deux cas).
Et en effet, selon les marques ils ont des API différentes qui fonctionnent essentiellement de la même manière. Un SDK n'est pas forcément nécessaire, en fait ça peut fonctionner entièrement à base d'Intents Android. Une application Android du constructeur tourne en tâche de fond et traite ces intents. On a des intents qui permettent d'allumer le lecteur de codes barres, commencer à flasher, recevoir le résultat, l'éteindre, pousser des réglages, gérer des profils de réglage. Par défaut, et parce que c'est plus facile à prendre en main au début et que ça permet de faire marcher le scan dans une page web classique, le scanner du téléphone se comporte comme un clavier et envoie le code barres sous forme d'entrée clavier. Mais c'est moyennent fiable. C'est probablement mieux de désactiver ça parce qu'il y a peu de contrôle là dessus, c'est vaguement bugué, on ne sait pas forcément quand la saisie se termine même s'il y a généralement la possibilité de définir un préfixe et/ou un suffixe / de demander ou pas d'envoyer un évènement "touche entrée", etc.
Les appareils Zebra répondent à l'API DataWedge de Zebra alors que le Honeywell EDA52 répond à sa propre API, qui ressemble pas mal. Pour caricaturer, c'est quasi les mêmes intents avec les mêmes données, mais avec des noms et des propriétés différentes. Il est possible de piloter les deux types de d'appareils à partir de la même activité Android, et d'envoyer les deux types d'intent quitte à ce que l'un des deux soit envoyé dans le cosmos à chaque fois. Ça marche, je l'ai fait, mais je veux bien croire que ça ne passe pas à l'échelle s'il faut prendre en charge plusieurs modèles et je confirme que la documentation est un peu inégale et que c'est beaucoup d'essais-erreurs, et les intents Android j'ai trouvé ça pénible à déboguer (peut être à cause de mon manque d'expérience), donc une bibliothèque pour unifier tout ça est la bienvenue. Ça permet effectivement certainement de ne pas s'enfermer chez un fournisseur en particulier.
Alors pourquoi Android ? Parce que ça permet de répondre à des cas d'usage où l'appareil doit être transportable et autonome (mobile, quoi) et de faire appel à des prestataires / d'embaucher des développeurs / développeuses mobiles sans compétences / connaissances particulières, sans avoir besoin de réapprendre tout un système spécifique. Ça permet aussi aux constructeurs de ne pas tout redévelopper de zéro. Et ça permet de proposer une application mobile qui tournera sur un téléphone classique sans lecteur de codes barres avec une solution de repli qui s'appuie sur l'appareil photo du téléphone.
Et donc oui, je pense que c'est relativement répandu. On parle bien d'un "ordinateur" mobile complet, pas seulement un lecteur de codes barres qui a besoin d'être connecté à un ordinateur. Un modèle coûte probablement autour de 1000 €, ou un peu moins mais avec du support à acheter pour recevoir des mises à jour.
[^] # Re: Android ?
Posté par claudex . Évalué à 5.
Merci, je n'avais pas compris qu'Android était intégré au lecteur de code barre, je croyais que c'était à brancher sur un téléphone Android.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Android ?
Posté par DaSpood . Évalué à 7.
Il y a aussi effectivement le cas où le scanner est un appareil à part (souvent Bluetooth) qui peut se connecter à un smartphone comme à un ordinateur.
De manière générale, certains cas d'utilisation des scanners nécessitent de la mobilité (par exemple pour un livreur, dans un entrepôt, ou simplement avec un point relais pour lequel le matériel de scan est prêté temporairement). Dans ces cas là, un appareil plus petit qui se connecte à un smartphone (ou un smartphone avec scanner intégré) est beaucoup plus adapté qu'un scanner relié par câble à un ordinateur comme ce serait le cas avec une caisse enregistreuse de supermarché, qui reste toujours à la même place. Certains de ces scanners sont vraiment petits et se portent comme une bague autour du doigts.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.