HTML5 peut-il communiquer avec des périphériques tels que des scanners et des lecteurs de cartes de crédit?
Ma société écrit un logiciel qui s’installe sur les ordinateurs clients pour effectuer des transactions au point de vente. Le logiciel s'interface avec une variété de périphériques externes (imprimantes de reçus, scanners de codes à barres, lecteurs de cartes de crédit, etc.). Nous le faisons avec une application WinForms que nous avons créée dans Visual Studio à l'aide de la bibliothèque Microsoft OPOS, qui communique à son tour avec notre serveur de cloud (modèle client-serveur).
Il y a des inefficacités évidentes dans ce modèle, principalement avec les mises à jour. Je recherche d'autres moyens de communiquer avec ces périphériques sur le Web, de préférence via un navigateur Web. Pour autant que je sache, Java est l’une des seules technologies pouvant faire ce que nous cherchons (via un applet), et je suppose aussi qu’Adobe Flash (via le Plate-forme aérienne. Celles-ci sont viables, mais pas préférables car nous souhaitons utiliser notre logiciel sur des appareils mobiles compatibles Web.
Quelqu'un a-t-il des suggestions sur d'autres moyens de communiquer avec des périphériques externes sur le Web?
UPDATE (16 janvier 2019): Le API de gestion des informations d'identification a été annoncé. C'est actuellement uniquement supporté sur Chrome et Opera mais il semble prometteur. Les développeurs Google ont écrit n article pour en savoir plus sur les spécifications.
UPDATE (28 décembre 2016): Encore deux ans et une autre mise à jour. Celui-ci sera plus axé sur deux nouveaux développements que toute autre chose. Consultez la nouvelle section "WebUSB & Web BlueTooth" sous "API complète du périphérique". Mais la réponse reste la même.
MISE À JOUR (3 novembre 2014): Cela fait un peu plus de deux ans que le message original a été publié, mais la réponse reste généralement la même pour l'instant. Nous sommes toutefois plus proches de votre objectif initial dans plusieurs domaines.
RÉPONSE ORIGINALE:
Il y aurait plusieurs façons de s'y prendre.
Contexte
La spécification HTML5 est entrée dans l'état "Recommandation". Cela signifie que HTML5 est pratiquement configuré pour ce à quoi il ressemble. Cependant, j'utiliserai HTML5 de la même manière que tous les spécialistes du marketing du monde entier ont décidé qu'il était préférable. C'est-à-dire que je ne parlerai pas de HTML. Eh bien, dans la mesure où vous l'utiliserez à partir d'une page HTML, ce ne sera pas vraiment le cas. Ce dont je vais parler, c’est JavaScript (JS) et c’est un cheval de couleur différente . Mais à toutes fins pratiques, nous mettons tout cela dans la même rubrique que HTML5, qui a été décidé de vouloir dire "brillant et nouveau" maintenant.
En outre, les éléments dont je discute varieront en termes de support. Certains sont des projets très dépendants des navigateurs (comme des implémentations spécifiques à Chromium), et d'autres sont davantage axés sur les normes et que les navigateurs ne les implémentent peut-être pas encore. Je vais essayer de faire la distinction entre les deux au fur et à mesure.
API complète de l'appareil
Statut: entrant, mais pas prêt
La possibilité d'accéder aux périphériques à partir du navigateur fait des progrès lents mais réguliers. À l'heure actuelle, de nombreux navigateurs modernes ont accès à certains des périphériques les plus courants tels que la caméra ou manettes de je , mais ce sont tous des API de haut niveau. fournisseurs de navigateurs , les groupes de normalisation , et de nombreuses entreprises impliquées dans le Web tentent toutes de rendre les applications Web aussi puissantes que vos applications locales.
Mais les API que vous recherchez sont toujours en cours de développement. Pour votre cas particulier, et pour le cas plus général de connexion de votre application Web à la plupart des appareils, il nous reste encore quelques années à partir de quelque chose que nous pouvons utiliser. Si vous voulez voir ce qui se passe dans ce domaine, voici quelques éléments qui pourraient vous aider directement:
- API NFC (Web Near Field Communication)
Celui-ci peut malheureusement être mort dans l'eau pour l'instant. Mais il semblerait qu'à l'origine, certains membres du W3C (principalement Intel, semble-t-il) cherchaient à ajouter une API NFC au Web). - flux de capture multimédia
Le groupe WebRTC travaille sur un accès programmatique à des flux de média tels que la caméra, qui permettrait d’intégrer des éléments tels que la numérisation de codes à barres ou d’autres fonctionnalités. Cela a atteint le statut CR et est disponible dans les navigateurs , mais est moins utile en soi. - Bluetooth Web
Si vous aviez des outils compatibles Bluetooth, cette API vous aiderait à vous connecter à partir d’ordinateurs et d’appareils capables d’écouter et de se connecter. Le principal moteur pour le moment semble être l’équipe Chrome, y compris une implémentation expérimentale, mais je ne le considérerais pas encore prêt à l’utiliser pour le moment (voir "WebUSB & Web BlueTooth"). section). - WebUSB
Ceci permettrait un accès complet aux informations USB de bas niveau, y compris la liste des périphériques et l’interaction avec eux. Identique à Web BlueTooth, cela semble être le projet en cours Chrome pour les animaux domestiques, mais je ne voudrais pas non plus compter sur celui-ci (voir la section "WebUSB & Web BlueTooth"). - découverte du service résea
Si vous avez d'autres périphériques ou éléments sur le réseau qui diffusent et utilisent HTTP, cette API vous permettra de découvrir et d'interagir avec ces services. Aucune implémentation de navigateur, mais cela fait partie du brouillon du W3C.
À l'origine, Mozilla faisait avancer un certain nombre d'entre eux à cause de Boot2Gecko (ou Firefox OS). Cependant, avec l'annulation officielle de ce projet, nous ne voyons pas beaucoup de progrès de leur part dans ces domaines.
Les membres de l’équipe Chrome, cependant, semblent avoir décidé de plonger dedans et commencent à travailler non seulement pour ceux-ci, mais aussi en les plaçant dans des navigateurs. Ce qui nous amène à ...
WebUSB et Web BlueTooth
Comme les saucisses, il est préférable de ne pas savoir comment les standards Web sont élaborés
- Abraham Lincoln (probablement)
Il y a eu un peu de buzz dans ce domaine car cela ressemble à l'équipe de Chrome) qui en a profité pour développer ses propres spécifications expérimentales et qui ont développé leurs propres spécifications. Ce qui est génial! que vous espériez.
Chaque fournisseur de navigateur et groupe de contributeurs W3C a son propre style et apporte sa contribution aux spécifications à sa manière. Le résultat est généralement une spécification assez convenable sur laquelle les navigateurs se sont mis d’accord. Mais passer de rien à quelque chose est ... désordonné. Vraiment en désordre. Et c'est un processus très long. Cela n'aboutit pas toujours à une bonne spécification (ouais, je parle de votre compromis Florian ...) mais même si c'est le cas, cela prend un certain temps.
Cependant, il semble que Google ait développé cette version de la spéc. Et, selon mon expérience, l'approche de Google en ce qui concerne les spécifications est toujours un peu ... eh bien ... si je mets de côté mes opinions personnelles, nous dirons "gung-ho". Ils ont tendance à plonger dans les profondeurs. Et cela semble être ce qu'ils ont fait ici.
Je doute fortement que ces spécifications ou implémentations ressemblent à cela quand elles deviennent des standards . Et il n'y a rien de mal à ça. Cela fait partie du processus. Mais je ne voudrais pas m'appuyer sur cette implémentation ou développer un code ou des produits pour contrer cela. Il s'agit d'une fonctionnalité sans précédent sur le Web et tous les éditeurs de navigateurs vont vouloir avoir leur mot à dire.
Cela dit, c'est vraiment bien. L'une des choses que Google fait souvent (pour le meilleur ou pour le pire) avec de telles situations est de forcer la conversation et de faire avancer les choses. Et avoir une fonctionnalité intégrée dans le navigateur, même une fonctionnalité expérimentale, peut faire monter la pression sur la demande. Il est donc possible que nous constations bientôt d'autres progrès dans ce domaine.
PhoneGap Apache Cordova. Vous savez, pour votre téléphone
Statut: pas encore complet et téléphone seulement
Apache Cordova , précédemment Adobe PhoneGap , est un moyen d'écrire votre programme en HTML, CSS et JS qui vous permet d'accéder à des fonctionnalités de niveau inférieur, telles que les téléphones, et de les compiler. à travers les appareils. Ce serait un moyen de mettre en œuvre votre programme, mais ce serait une application téléphonique, pas nécessairement une application de bureau. Une option à considérer et quelque chose que je pensais mentionner.
Cordova implémente déjà quelques-unes des fonctionnalités ci-dessus, mais n’en possède pas les plus puissantes telles que NFC ou BlueTooth.
La solution Native-App (pour Windows 8)
Statut: Possible, mais application spécifique au système d'exploitation et au bureau
Windows 8 offre la possibilité de créer des applications en HTML et JS. Cela vous permettrait d'accéder facilement aux fonctionnalités de niveau inférieur du système d'exploitation via leur API . À première vue, il est assez vaste et vous pouvez en faire beaucoup. Vous avez cependant mentionné le support inter-OS, ce qui vous limite évidemment à un seul OS.
C'est tellement Flash-y!
Statut: en train de mourir/mort, impossible en tant qu'application Web
Flash n'aura pas d'accès direct au système via le Web. Vous pouvez créer une application AIR, mais cela irait à l’encontre du but de l’avoir sur le Web. En outre, le support Flash sur mobile, et sur le Web, semble-t-il, est en déclin.
NodeJS
Statut: peut être un peu pénible et uniquement possible en tant qu'application de bureau
Les applications NodeJS et JS ont en quelque sorte été un sujet brûlant ces deux dernières années. Je n'en ai pas parlé dans mon message original car je sentais que ce n'était pas encore tout à fait là. Cependant, les choses ont progressé et il est beaucoup plus proche d’être prêts pour ce genre de chose, et a le soutien et la puissance d’une base d’utilisateurs croissante. Cela dit, dans votre cas particulier, je ne recommanderais pas de l'utiliser. Cela devrait être local sur la machine des utilisateurs, et en raison de l'état actuel de NodeJS (et de moteurs similaires), il faudrait beaucoup de configuration supplémentaire qui compliquerait un peu les choses.
Vous pouvez donc créer une application utilisant HTML, CSS et JS avec NodeJS ou des moteurs similaires et disposer d’un accès de bas niveau à ce dont vous avez besoin, mais cela doit être local et cela nécessiterait plus de travail que vous ne le voudriez certainement pas. le temps que vous souhaitez installer pour un client.
... Maintenant où étais-je?
Alors, où en sommes-nous? Eh bien, c'est simple: si vous voulez une seule langue/un ensemble de code comme base de code, HTML/CSS/JS ne sont pas une bonne option ... pour le moment. Mais ils pourraient être un jour. Pour le moment, vos options se limitent à ce que vous estimez être le mieux pour votre client. Java est une option stable que vous avez énumérée, mais qui a évidemment ses propres inconvénients. Au fur et à mesure que le Web se développera, nous verrons beaucoup de choses vraiment sympas sortir de la nouvelle fonctionnalité, mais nous avons encore du chemin à faire.
Plus de lecture:
C'est possible, mais cela devrait être fait indirectement. En théorie, vous pouvez écrire un serveur de socket dans un langage de bas niveau, qui obtient les E/S et envoie les E/S via le socket (relais, je suppose). HTML5 utilise WebSockets ou un équivalent pour communiquer avec ce serveur de socket.
Maintenant, cela peut être réalisé avec WebUSB API.
C'est disponible dans Chrome depuis la version 54.
Il s'agit d'un brouillon de l'éditeur du W3C. Nous pouvons donc espérer qu'il sera adopté par d'autres éditeurs de navigateurs ...
J'y ai beaucoup réfléchi ces derniers temps ... ayez une application de point de vente écrite pour la plupart en VB6, en tenant compte de ce que vous feriez ensuite. HTML5 est une option et je pensais utiliser VSPE pour transférer les données de série dans le JS.
http://www.eterlogic.com/Products.VSPE.html
J'adore ce produit! Cela fonctionne très bien pour obtenir du trafic en série là où vous en avez besoin, alors je pense que cela fonctionnerait bien, du moins comme preuve de concept pour vous permettre de continuer. Vous voudrez utiliser une combinaison de types "connecteur" avec les "tcpclient" et "tcpserver".
Pour mémoire, une méthode qui fonctionne bien en 2016 (depuis le chrome 26), mais qui doit être retirée au cours des 2 prochaines années consiste à déployer votre code HTML 5 en tant que chrome app et utilisez chrome.usb (ou chrome.serial ou chrome.bluetooth).
J'utilise actuellement chrome.usb et envisage de migrer vers une application Web à l'aide de WebUSB API (voir la réponse de Supersharp), qui, je l'espère, sera adopté à la veille de la fermeture de Google chrome applications. ????.