webusb - ¿Puede HTML5 comunicarse con periféricos como escáneres y lectores de tarjetas de crédito?
html5 fingerprint reader (5)
Ahora se puede lograr con la API de WebUSB .
Está disponible en Chrome desde la versión 54.
Es un borrador del editor del W3C, por lo que podemos esperar (esperar) que sea adoptado por otros proveedores de navegadores ...
Mi empresa escribe software que se instala en las máquinas cliente para realizar transacciones en el punto de venta. El software interactúa con una variedad de periféricos externos (impresoras de recibos, lectores de códigos de barras, lectores de tarjetas de crédito, etc.). Hacemos esto con una aplicación WinForms que creamos en Visual Studio usando la biblioteca Microsoft OPOS, que a su vez se comunica con nuestro servidor en la nube (un modelo cliente-servidor).
Hay obvias ineficiencias en este modelo, principalmente con las actualizaciones. Estoy investigando otras formas de comunicarme con estos periféricos a través de la web, preferiblemente a través del navegador web. Por lo que sé, Java es una de las únicas tecnologías que pueden hacer lo que estamos buscando (a través de un applet), y supongo que Adobe Flash también (a través de la plataforma Air). Estos son viables, pero no preferibles porque queremos ejecutar nuestro software en dispositivos móviles habilitados para la web.
¿Alguien tiene sugerencias sobre otras formas de comunicarse con periféricos externos a través de la web?
Esto es posible, pero tendría que hacerse indirectamente. En teoría, podría escribir un servidor de socket en un lenguaje de bajo nivel, que obtenga E / S y envíe la E / S a través del socket (retransmisión, supongo). HTML5 utiliza WebSockets, o algún equivalente para comunicarse con este servidor de socket.
He estado pensando mucho en esto últimamente ... tengo una aplicación POS mayormente escrita en VB6, considerando qué hacer a continuación. HTML5 es una opción y pensé que usaría VSPE para incorporar el material serial al JS.
http://www.eterlogic.com/Products.VSPE.html
Me encanta este producto! Funciona muy bien para obtener tráfico serial donde lo necesite, por lo que creo que funcionaría bien, al menos como una prueba de concepto para que pueda comenzar. Querrá usar una combinación de tipos de "conector" junto con "tcpclient" y "tcpserver".
Solo para el registro, un método que funciona bien en 2016 (desde Chrome 26), pero que se retirará en los próximos 2 años es implementar su html5 como una aplicación de Chrome y usar chrome.usb (o chrome.serial o Chrome). Bluetooth).
Actualmente estoy usando chrome.usb y estoy planeando migrar a una aplicación web usando la WebUSB (ver la respuesta de WebUSB ), que espero que se adopte en el momento en que Google suspenda las aplicaciones de Chrome.
ACTUALIZACIÓN (28 de diciembre de 2016): Otro par de años pasados y otra actualización. Este estará más enfocado en dos nuevos desarrollos que en cualquier otra cosa. Consulte la nueva sección "WebUSB & Web BlueTooth" en "Full Device API". Pero la respuesta sigue siendo la misma.
ACTUALIZACIÓN (3 de noviembre de 2014): Han pasado poco más de dos años desde que se realizó la publicación original, pero la respuesta sigue siendo casi la misma por ahora. Sin embargo, estamos más cerca de su objetivo original en varias áreas.
RESPUESTA ORIGINAL:
Habría varias maneras de hacer esto.
Fondo
La especificación HTML5 ha entrado en el estado de "Recomendación". Esto significa que HTML5 está más o menos configurado para lo que parece. Sin embargo, usaré HTML5 de la misma manera que cada persona de marketing en el mundo ha decidido que es lo mejor. Es decir, no voy a hablar de HTML. Bueno, lo haré, en la medida en que lo utilices desde una página HTML, pero no realmente. Lo que realmente voy a discutir es JavaScript (JS) y eso es un caballo de un color diferente . Pero para todos los efectos, lo ponemos todo bajo el mismo encabezado que HTML5, que ahora se ha decidido a significar "brillante y nuevo".
Además, los elementos que estoy discutiendo variarán en soporte. Algunos son proyectos que dependen mucho del navegador (como las implementaciones específicas de Chromium), y otros son proyectos más basados en estándares que aún no han implementado o experimentado con los navegadores. Intentaré distinguir entre los dos a medida que avanzo.
API de dispositivo completo
Estado: Entrante, pero no listo
El hecho de poder acceder a los dispositivos desde el navegador está progresando de forma lenta pero constante. En este momento, muchos navegadores modernos tienen acceso a algunos de los dispositivos más comunes, como la cámara o los gamepads , pero todos son API de alto nivel. Los proveedores de navegadores , los grupos de estándares y muchas compañías involucradas con la web intentan hacer que las aplicaciones web sean tan poderosas como sus aplicaciones locales.
Pero las API que está buscando todavía están en progreso y están muy lejos. Para su caso particular, y para el caso más general de conectar su aplicación web a la mayoría de los dispositivos, todavía estamos a unos años de algo que podamos usar. Si desea ver qué cosas asombrosas están surgiendo en ese campo, aquí hay solo algunos elementos que pueden ayudarlo directamente:
- API de comunicación de campo cercano (NFC)
Esta desgraciadamente puede estar muerta en el agua por ahora. Pero parece que originalmente algunas personas en el W3C (en su mayoría parece que Intel) estaban considerando agregar una API NFC a la web. - Transmisiones de captura de medios
El grupo WebRTC está trabajando en el acceso programático a transmisiones multimedia como la cámara, lo que permitiría integrar elementos como el escaneo de códigos de barras u otras características. Esto ha alcanzado el estado CR y está disponible en los navegadores , pero es menos útil por sí solo. - Web bluetooth
Si tuviera herramientas compatibles con Bluetooth, esta API lo ayudaría a conectarse con ellas desde computadoras y dispositivos que pudieran escuchar y conectarse. El controlador principal para esto en este momento parece ser el equipo de Chrome, incluida una implementación experimental, pero aún no lo consideraría listo para usar (consulte la sección "WebUSB y Web BlueTooth"). - WebUSB
Esto permitiría un acceso completo a información USB de bajo nivel, incluida la lista de dispositivos e interactuar con ellos. Igual que Web BlueTooth, este parece ser el proyecto actual de Chrome, pero tampoco me gustaría confiar en él (consulte la sección "WebUSB y Web BlueTooth"). - Descubrimiento de servicio de red
Si tiene otros dispositivos o elementos en la red que transmiten y usan HTTP, esta API le permitirá descubrir e interactuar con estos servicios. No hay implementación del navegador, pero está en un borrador de trabajo para el W3C.
Originalmente, Mozilla estaba empujando varios de estos hacia adelante debido a Boot2Gecko (o Firefox OS). Sin embargo, con el proyecto cancelado oficialmente, no estamos viendo mucho progreso en estas áreas ahora.
Sin embargo, los miembros del equipo de Chrome parecen haber decidido sumergirse y comenzar a trabajar no solo para lograrlos, sino también para ponerlos en vivo en los navegadores. Lo que nos lleva a ...
WebUSB y Web BlueTooth
Al igual que las salchichas, es mejor no saber cómo se hacen los estándares web
-Abraham Lincoln (probablemente)
Ha habido un poco de entusiasmo en esta área, ya que parece que el equipo de Chrome se coló en ellas como características experimentales y desarrolló sus propias especificaciones para ello. ¡Lo cual es genial! Tal vez no de la manera que esperabas.
Cada proveedor de navegador y grupo de contribuyentes de W3C tienen su propio estilo y hacen contribuciones a las especificaciones a su manera. El resultado suele ser una especificación bastante decente que los navegadores han acordado. Pero pasar de la nada a algo es ... desordenado. Muy desordenado Y es todo un proceso muchas veces. No siempre resulta en una buena especificación (sí, estoy hablando de tu compromiso Florian ...) pero incluso cuando lo hace, toma un tiempo.
Sin embargo, parece que Google desarrolló esta versión de la especificación por su cuenta. Y, según mi experiencia, el enfoque de Google con respecto a las especificaciones es siempre un poco ... bueno ... dejando de lado mis opiniones personales, diremos "gung-ho". Tienden a sumergirse directamente en el extremo profundo. Y eso parece ser lo que han hecho aquí.
Dudo mucho que estas especificaciones o implementaciones se vean así cuando se conviertan en estándares . Y no hay nada de malo en eso. Eso es parte del proceso. Pero no me atrevería a confiar en esta implementación ni a desarrollar ningún código o producto en su contra. Esta es una característica sin precedentes en la web y todos los proveedores de navegadores querrán tener una gran opinión sobre esto.
Dicho esto, esto es realmente bueno. Una de las cosas que Google hace a menudo (para bien o para mal) con situaciones como esta es forzar la conversación y puede impulsar las cosas. Y tener una característica enviada en el navegador, incluso una característica experimental, puede aumentar la demanda de la misma. Para que podamos ver más progreso en esta área pronto.
PhoneGap Apache Cordova. Ya sabes, para tu telefono
Estado: no está completo y solo teléfono
Apache Cordova , anteriormente Adobe PhoneGap , es una forma de escribir su programa en HTML, CSS y JS que le permite acceder a una funcionalidad de nivel inferior en cosas como teléfonos y compilar en todos los dispositivos. Esta sería una forma de implementar su programa, pero sería una aplicación de teléfono, no necesariamente una de escritorio. Una opción a considerar, y algo que pensé mencionar.
Cordova implementa algunas de las características anteriores, pero no tiene algunas de las más poderosas como NFC o BlueTooth.
La solución Native-App (para Windows 8)
Estado: posible, pero específico del sistema operativo y aplicación de escritorio
Windows 8 ofrece la posibilidad de crear aplicaciones en HTML y JS. Esto le permitiría acceder fácilmente a la funcionalidad de nivel inferior en el sistema operativo a través de su API . Por su aspecto, es bastante extenso y se puede hacer mucho. Sin embargo, mencionó el soporte de sistemas operativos cruzados, y esto obviamente lo limita a un solo sistema operativo.
Es tan Flash-y!
Estado: Muriendo / Muerto, no es posible como una aplicación web
Flash no tendrá acceso directo al sistema a través de la web. Podría crear una aplicación de AIR, pero eso anulará el propósito de tenerla basada en la web. Además, el soporte de Flash en dispositivos móviles, y en la web parece, está en declive.
NodeJS
Estado: puede ser un poco molesto y solo es posible como una aplicación de escritorio
Las aplicaciones NodeJS y JS han sido un tema candente en los últimos dos años. No lo discutí en mi publicación original porque sentí que aún no estaba allí. Sin embargo, las cosas han progresado y está mucho más cerca de estar listo para este tipo de cosas, y tiene el respaldo y el poder de una base de usuarios en crecimiento. Dicho esto, para su caso particular, no recomendaría usarlo. Tendría que ser local en la máquina de los usuarios, y debido a que NodeJS (y motores similares) se encuentran en este momento, requeriría mucha configuración y configuración adicionales que complicarían un poco las cosas.
Por lo tanto, podría crear una aplicación utilizando HTML, CSS y JS con NodeJS o motores similares y tener acceso de bajo nivel a lo que necesita, pero tiene que ser local, y tomará más trabajo del que estoy seguro que desea hacer cada Tiempo que le gustaría instalarlo para un cliente.
... ahora donde estaba yo?
Entonces, ¿dónde nos deja eso? Bueno, simple: si desea un solo idioma / conjunto de código como su base de código, HTML / CSS / JS no es una gran opción ... todavía. Pero podrían ser algún día. Por ahora, sus opciones están limitadas a lo que usted considera mejor para su cliente. Java es una opción estable que mencionaste, pero obviamente tiene sus propios inconvenientes. A medida que se desarrolla la web, creo que veremos muchas cosas realmente geniales que surgen de la nueva funcionalidad, pero aún tenemos mucho camino por recorrer.