CONTACT, devis
Contacter Productivix Sarl : développement applications de gestion mobile de traçabilité code-barre, RFID, génériques par smartphone Android ou sur mesure avec backend, terminaux durcis et imprimantes - contact par email avec ce formulaire
TEL +33 437 051 384 / Skype : Productivix
Module ergonomie app de lecture : diriger le scan vers le champ voulu
en passant par le SDK constructeur, aussi pour Rfid
Qui n’a jamais utilisé un lecteur de code barre sur un terminal et qu’au moment du scan la donnée ne va pas au bon endroit ?
Explications : la solution réside dans l’emploi du "SDK" ou de nos applications dédiées au scan de codes à barres ! Ce module est utilisé dans nos applications AndroidFiche conseil des solutions pour augmenter l’ergonomie de vos applications mobiles,
ainsi qu’au niveau de la RFID.
Pré-requis techniques et vocabulaire
Tout d’abord on parle ici de mettre en œuvre une application sur un terminal mobile, pas de douchette.
Le mode "Wedge" est un programme mis à disposition par le constructeur de presque chaque modèle de terminaux pour assister l’utilisateur à transcrire l’image lue par le scanner ou l’imageur en code lisible par l’humain et l’envoyer sur le champ de données de l’écran. Il est paramétrable dans chaque terminal, ce qui est contraignant et peut être facilement modifiable par mégarde par l’opérateur.
Le "SDK" (Software Development Kit) est le package de programmes mis à disposition par le constructeur pour les programmeurs pour capturer la donnée directement en sortie du scanner ou de l’imageur. Le programmeur en prend soin après. Il peut y avoir un SKD par terminal ou par gamme de terminaux en en tous les cas pour Android et un autre pour Windows CE, Embedded, etc
Chez nous, ces SDK sont intégrés dans nos applications.
Ils ne sont pas réalisés pour chaque terminaux ou gamme et dépendent de la mise à disposition des modèles et des kits par les constructeurs.
Le comportement de l’application réalisée et de son confort d’usage dépend de la méthode employée par le développeur, des moyens mis à sa disposition et du choix de la machine.
Nous avons fait un état des lieux de la situation à date des comportements possibles et des moyens mis à disposition par les éditeurs et les constructeurs.
On invite pas là même les constructeurs de terminaux à nous contacter directement pour se faire intégrer et ainsi être plus facilement être référencés.
Voici un tableau comparatif des situations d’exploitation prévisibles du scan par l’utilisateur :
| Situation de scan | Par SDK | Par Wedge |
|---|---|---|
| page avec 1 champ sans toucher l’écran | la donnée scannée va dans le champ | la donnée scannée va dans le champ |
| page avec 1 champ en touchant un autre bouton que le champ | la donnée se perd | la données cannée va dans le champ |
| page avec plusieurs champ, sans toucher l’écran | la donnée scannée va dans le bon champ | la donnée va dans le bon champ |
| page avec plusieurs champs, en touchant l’écran dans un autre champs | la donnée scannée va dans le bon champ | la donnée va dans le mauvais champ |
| page avec plusieurs champs, sans champ de codes barre | aucune donnée scannée n’arrive | si scan : un champ avec le "focus" (touché) la stocke |
| Étiquette avec plusieurs codes barres avec une lettre différente au début, ou plusieurs polices de codes | chaque donnée scannée va dans le bon champ | la donnée va dans le mauvais champ |
Il est donc clair qu’une application complexe développée avec l’usage du SDK sera plus confortable à utiliser et générera moins d’erreurs.
Remarque : des pro du paramétrage du Wedge (de chaque constructeur) et plus particulièrement sur Android pourront améliorer leur situation en le paramétrant plus finement : il faut reproduire ensuite le paramétrage sur plusieurs machines (utilitaire constructeur), mais ceci dépend de la variété du parc de machines.
Voir aussi : Des économies et une cadence de scan code-barre acceptable avec nos logiciels pour appareil photo