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 raphj (site web personnel) . En réponse au journal Enioka Scan: Release 2.0.0. É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.