Este grupo especializado despúes de ciertos días de investigación y recopilación de de datos, obtuvimos la solución, esperamos que todo este artículo sea de gran utilidad para tu proyecto.
Solución:
ACTUALIZACIÓN (16 de enero de 2019): Se ha anunciado la API de gestión de credenciales. Actualmente solo es compatible con Chrome y Opera, pero parece prometedor. Los desarrolladores de Google escribieron un artículo sobre la especificación.
ACTUALIZACIÓN (28 de diciembre de 2016): Pasaron un par de años más y otra actualización. Este estará más enfocado en dos nuevos desarrollos que en cualquier otra cosa. Consulte la nueva sección “WebUSB y Web BlueTooth” en “API de dispositivo completo”. 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 hizo la publicación original, pero la respuesta sigue siendo la misma por ahora. Sin embargo, estamos más cerca de su objetivo original en varias áreas.
RESPUESTA ORIGINAL:
Habría varias formas de hacerlo.
Fondo
La especificación HTML5 ha entrado en el estado “Recomendación”. Esto significa que HTML5 está bastante configurado para lo que parece. Sin embargo, usaré HTML5 de la misma manera que todos los especialistas en marketing del mundo han decidido que es lo mejor. Es decir, no hablaré de HTML. Bueno, lo haré, en la medida en que lo utilice desde una página HTML, pero no realmente. Lo que realmente discutiré es JavaScript (JS) y ese es un caballo de un color diferente. Pero para todos los efectos, lo ponemos todo bajo el mismo título que HTML5, que ahora se ha decidido que significa “brillante y nuevo”.
Además, los elementos que estoy discutiendo variarán en apoyo. Algunos son proyectos muy dependientes del navegador (como implementaciones específicas de Chromium), y algunos son proyectos más impulsados por estándares que pueden no tener navegadores implementando o experimentando con ellos todavía. Intentaré distinguir entre los dos a medida que avance.
API de dispositivo completo
Estado: entrante, pero no listo
Poder acceder a los dispositivos desde el navegador es un progreso lento pero constante. En este momento, muchos navegadores modernos tienen acceso a algunos de los dispositivos más comunes, como la cámara o los mandos, pero todos son API de alto nivel. Los proveedores de navegadores, los grupos de estándares y muchas empresas involucradas con la web están tratando de 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 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 algunos años de algo que podamos usar. Si desea ver qué cosas increíbles están surgiendo en ese campo, aquí hay solo algunos elementos seleccionados que pueden ayudarlo directamente:
- API de comunicación de campo cercano web (NFC)
Este, lamentablemente, puede estar muerto en el agua por ahora. Pero parece que originalmente algunas personas en el W3C (parece que en su mayoría Intel) estaban buscando agregar una API NFC a la web. - Secuencias de captura de medios
El grupo WebRTC está trabajando en el acceso programático a transmisiones de medios como la cámara, lo que permitiría integrar elementos como el escaneo de códigos de barras u otras funciones. Esto ha alcanzado el estado CR y está disponible en los navegadores, pero es menos útil por sí solo. - Web Bluetooth
Si tuviera herramientas con capacidad bluetooth, esta API lo ayudaría a conectarse con ellas desde computadoras y dispositivos que pudieran escuchar y conectarse. El controlador principal de esto en este momento parece ser el equipo de Chrome, incluida una implementación experimental, pero no lo consideraría listo para usar en ningún lugar todavía (consulte la sección “WebUSB y Web BlueTooth”). - WebUSB
Esto permitiría el acceso completo a la información USB de bajo nivel, incluida la lista de dispositivos e interactuar con ellos. Al igual que Web BlueTooth, este parece ser un proyecto favorito de Chrome actual, pero tampoco confiaría en él (consulte la sección “WebUSB y Web BlueTooth”). - Descubrimiento de servicios 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 de navegador, pero está en un borrador de trabajo para el W3C.
Originalmente, Mozilla estaba impulsando varios de estos debido a Boot2Gecko (o Firefox OS). Sin embargo, con ese proyecto oficialmente cancelado, no estamos viendo mucho progreso de ellos en estas áreas ahora.
Los miembros del equipo de Chrome, sin embargo, parecen haber decidido sumergirse y comenzar a trabajar no solo en estos, sino a 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 elaboran los estándares web
-Abraham Lincoln (probablemente)
Ha habido un poco de rumores en esta área, ya que parece que el equipo de Chrome se coló en estas como características experimentales y desarrolló su propia especificación para ello. ¡Lo cual es genial! Quizás no de la manera que esperabas.
Cada proveedor de navegadores y grupo de colaboradores del W3C tiene su propio estilo y contribuye a las especificaciones a su manera. El resultado es generalmente una especificación bastante decente que los navegadores han acordado. Pero pasar de la nada a algo es … complicado. Realmente 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, lleva un tiempo.
Sin embargo, parece que Google desarrolló esta versión de la especificación por su cuenta. Y, en mi experiencia, el enfoque de Google a las especificaciones es siempre un poco … bueno … dejando a un lado mis opiniones personales, diremos “gung-ho”. Tienden a sumergirse directamente en lo más 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 confiaría en esta implementación ni desarrollaría 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 participación en esto.
Dicho esto, esto es realmente bueno. Una de las cosas que Google suele hacer (para bien o para mal) en situaciones como esta es forzar la conversación y puede impulsar las cosas. Y tener una función incluida en el navegador, incluso una función experimental, puede aumentar la demanda. Por lo tanto, es posible que veamos más avances en esta área pronto.
PhoneGap Apache Cordova. Ya sabes, para tu teléfono
Estado: no con todas las funciones 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 funciones de nivel inferior en cosas como teléfonos y compilar entre 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é que mencionaría.
Cordova ya 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 capacidad 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 lo que parece, es bastante extenso y puedes hacer mucho. Sin embargo, mencionaste la compatibilidad con varios sistemas operativos, y esto obviamente te limita a un sistema operativo.
¡Es tan deslumbrante!
Estado: moribundo / muerto, no es posible como 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 frustrará el propósito de tenerla basada en la web. Además, la compatibilidad con Flash en dispositivos móviles y, al parecer, en la web, está disminuyendo.
NodeJS
Estado: puede ser un poco molesto y solo es posible como aplicación de escritorio
Las aplicaciones NodeJS y JS han sido un tema candente en los últimos años. No lo hablé 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 cuenta con el apoyo 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 cómo son NodeJS (y motores similares) 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 usando 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ía más trabajo del que estoy seguro que desea hacer cada momento en el 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 base de código, HTML / CSS / JS no es una gran opción … todavía. Pero podrían serlo algún día. Por ahora, sus opciones se limitan a lo que crea que es mejor para su cliente. Java es una opción estable que enumeraste, pero obviamente tiene sus propios inconvenientes. A medida que la web se desarrolle, creo que veremos muchas cosas realmente interesantes que saldrán de la nueva funcionalidad, pero aún nos queda mucho camino por recorrer.
Más lectura:
- Brian.IO: más allá de HTML5
- Aplicaciones HTML5 en Windows 8
- Lista de Wikipedia de proyectos creados con JS
Esto es posible, pero tendría que hacerse de forma indirecta. En teoría, podría escribir un servidor de socket en un lenguaje de bajo nivel, que obtiene E / S y envía la E / S a través del socket (retransmitiendo, supongo). HTML5 usa WebSockets, o algún equivalente para comunicarse con este servidor de socket.
Ahora se puede lograr con WebUSB API.
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 …
Sección de Reseñas y Valoraciones
Si crees que ha resultado de provecho este post, nos gustaría que lo compartas con el resto juniors así contrubuyes a extender este contenido.