67

私の会社では、クライアント マシンにインストールして POS トランザクションを実行するソフトウェアを作成しています。このソフトウェアは、さまざまな外部周辺機器 (レシート プリンター、バーコード スキャナー、クレジット カード リーダーなど) とインターフェイスします。これは、Microsoft OPOS ライブラリを使用して Visual Studio で作成した WinForms アプリで行います。このアプリは、クラウド サーバーと通信します。

このモデルには、主に更新に関して明らかな非効率性があります。これらの周辺機器と Web 経由で、できれば Web ブラウザ経由で通信する他の方法を研究しています。私が知る限り、Java は私たちが探していることを (アプレット経由で) 実行できる唯一のテクノロジの 1 つであり、Adobe Flash も (Air プラットフォーム経由で) 実行できると思います。これらは実行可能ですが、Web 対応のモバイル デバイスでソフトウェアを実行したいため、好ましくありません。

Web 経由で外部周辺機器と通信する他の方法について提案がある人はいますか?

4

5 に答える 5

87

更新 (2019 年 1 月 16 日): Credential Management APIが発表されました。現在、Chrome と Opera でのみサポートされていますが、有望に見えます。Google Developers は、仕様について詳しく説明する記事を書きました。

更新 (2016 年 12 月 28 日):さらに数年が経過し、別の更新が行われました。これは、何よりも 2 つの新しい開発に重点を置いています。「Full Device API」の下にある新しい「WebUSB & Web BlueTooth」セクションを参照してください。しかし、答えは同じままです。

更新 (2014 年 11 月 3 日):最初の投稿が作成されてから 2 年以上が経過しましたが、答えは今のところほとんど同じです。ただし、いくつかの領域で当初の目標に近づいています。

元の答え:

これについては、いくつかの方法があります。

バックグラウンド

HTML5 仕様は「推奨」状態に入りました。これは、HTML5 がどのように見えるかについてほぼ設定されていることを意味します。ただし、世界中のすべてのマーケティング担当者が最適と判断したのと同じ方法で HTML5 を使用します。つまり、HTML については説明しません。まあ、HTML ページから利用する限りはそうしますが、実際にはそうではありません。私が実際に議論するのは JavaScript (JS) であり、それは別の色の馬です。しかし、すべての意図と目的のために、HTML5 と同じ見出しの下にすべてを置いています。HTML5 は、現在「光沢があり、新しい」という意味であると決定されています。

また、私が議論している項目はサポートが異なります。ブラウザーに大きく依存するプロジェクト (Chromium 固有の実装など) もあれば、ブラウザーがまだ実装または実験を行っていない標準主導のプロジェクトもあります。話を進めながら、両者を区別しようと思います。

完全なデバイス API

ステータス: 受信中ですが、準備ができていません

ブラウザーからデバイスにアクセスできるようになることは、ゆっくりではありますが着実に進んでいます。現在、最新のブラウザの多くは、カメラゲームパッドなどのより一般的なデバイスにアクセスできますが、それらはすべて高レベルの API です。ブラウザー ベンダー標準化団体、および Web に関係する多くの企業はすべて、ローカル アプリケーションと同じくらい強力な Web アプリケーションを作成しようとしています。

しかし、あなたが探している API はまだ進行中であり、道は遠いです。あなたの特定のケース、および Web アプリをほとんどのデバイスに接続するより一般的なケースでは、使用できるようになるまでにはまだ数年かかります。その分野でどんな素晴らしいことが起きているのか知りたい場合は、直接役立つ可能性のあるいくつかの項目を以下に示します。

  • Web 近距離無線通信 (NFC) API
    残念ながら、これは今のところ役に立たない可能性があります。しかし、もともと W3C の何人かの人々 (ほとんどが Intel のように見えます) は、NFC API を Web に追加することを検討していたようです。
  • メディア キャプチャ ストリーム
    WebRTC グループは、カメラなどのメディア ストリームへのプログラムによるアクセスに取り組んでおり、バーコード スキャンやその他の機能などを統合できます。これは CR ステータスに達しており、ブラウザで利用できますが、単独ではあまり役に立ちません。
  • Web Bluetooth Bluetooth
    対応のツールをお持ちの場合、この API は、リッスンして接続できるコンピューターやデバイスからツールに接続するのに役立ちます。現時点では、実験的な実装を含む Chrome チームのように思われますが、まだ使用する準備ができているとは考えていません (「WebUSB & Web BlueTooth」セクションを参照)。
  • WebUSB
    これにより、デバイスの一覧表示やデバイスとの対話など、低レベルの USB 情報への完全なアクセスが可能になります。Web BlueTooth と同じように、これは現在の Chrome ペット プロジェクトのようですが、私もそれに依存しません (「WebUSB & Web BlueTooth」セクションを参照)。
  • ネットワーク サービスの検出
    ネットワーク上に HTTP をブロードキャストして使用する他のデバイスまたはアイテムがある場合、この API を使用すると、これらのサービスを検出して操作できます。ブラウザーの実装はありませんが、W3C のワーキング ドラフトの段階にあります。

もともと、Mozilla は Boot2Gecko (または Firefox OS) のために、これらの多くを推進していました。しかし、そのプロジェクトが正式にキャンセルされたため、現在、これらの分野での彼らの進歩はあまり見られません.

しかし、Chrome チームのメンバーは、これらに飛び込むだけでなく、ブラウザーでライブにすることを決定したようです。それは私たちを導く...

WebUSB & Web BlueTooth

ソーセージと同じように、Web 標準がどのように作成されているかを知らない方がよい -
Abraham Lincoln (おそらく)

Chrome チームがこれらを実験的な機能としてこっそり取り入れ、独自の仕様を開発したように見えるため、この分野では少し話題になっています。これは素晴らしいです!あなたが望んでいた方法ではないかもしれません。

各ブラウザー ベンダーと W3C コントリビューター グループには独自のスタイルがあり、独自の方法で仕様に貢献しています。その結果、通常、ブラウザーが合意したかなり適切な仕様が得られます。しかし、何もないところから何かを作るのは... 厄介です。本当に厄介です。そして、多くの場合、かなりのプロセスです。常に良い仕様が得られるとは限りません (ええ、私はあなたのフロリアンの妥協について話しているのです...)。

ただし、Google がこのバージョンの仕様を独自に開発したようです。そして、私の経験では、仕様に対する Google のアプローチは常に少し… まあ… 私の個人的な意見は脇に置いて、「ガンホー」と言います。彼らはただ深いところに飛び込む傾向があります。そして、それが彼らがここでやったことのようです。

これらの仕様や実装が標準になったときに、このようなものになるとは思えません。そして、それは何も悪いことではありません。それはプロセスの一部です。しかし、私はこの実装に依存したり、それに対するコードや製品を開発したりするつもりはありません。これは Web では前例のない機能であり、すべてのブラウザー ベンダーはこれについて大きな発言権を持ちたいと考えています。

とは言え、これは実に良い。このような状況で Google が (良くも悪くも) よく行うことの 1 つは、会話を強制し、物事を進めることができることです。また、実験的な機能であっても、ブラウザーに機能が組み込まれていると、その機能に対する需要が高まる可能性があります。そのため、この分野でさらに進展が見られるかもしれません。

フォンギャップアパッチコルドバ。ほら、あなたの電話のために

ステータス: フル機能ではなく、電話のみ

Apache Cordova (以前のAdob​​e PhoneGap ) は、HTML、CSS、および JS でプログラムを作成する方法であり、電話などで下位レベルの機能にアクセスしたり、デバイス間でコンパイルしたりできます。これはプログラムを実装する方法ですが、必ずしもデスクトップ アプリケーションではなく、電話アプリケーションになります。考慮すべきオプションであり、私が言及したいと思ったものです。

Cordova は、上記の機能のいくつかを既に実装していますが、NFC や BlueTooth などのより強力な機能は実装していません。

ネイティブ アプリ ソリューション (Windows 8 用)

ステータス: 可能ですが、OS 固有およびデスクトップ アプリ

Windows 8 は、HTML および JS でアプリケーションを構築する機能を提供します。これにより、APIを介して OS の下位レベルの機能に簡単にアクセスできます。見た目からしてかなり広くて、いろいろできます。ただし、クロス OS サポートについて言及しましたが、これは明らかに 1 つの OS に制限されます。

それはとてもFlash-yです!

ステータス: 瀕死/死亡、Web アプリとしては不可

Flash は Web 経由でシステムに直接アクセスできません。AIR アプリケーションを作成することもできますが、それでは Web ベースにするという目的が台無しになります。さらに、モバイルや Web での Flash のサポートは減少傾向にあります。

NodeJS

ステータス: 少し面倒で、デスクトップ アプリとしてのみ可能です。

NodeJS および JS アプリケーションは、ここ数年、ホットな話題になっています。まだ十分ではないと感じたので、元の投稿では議論しませんでした。しかし、物事は進歩しており、この種の準備が整うまでにはかなり近づいており、拡大するユーザーベースのサポートと力を持っています. とはいえ、あなたの特定のケースでは、それを使用することはお勧めしません。ユーザーのマシン上でローカルにする必要があり、NodeJS (および同様のエンジン) が現時点でどのようになっているのかにより、多くの追加の構成とセットアップが必要になり、少し複雑になります。

したがって、HTML、CSS、および JS を NodeJS または同様のエンジンで使用してアプリを構築し、必要なものに低レベルでアクセスすることもできますが、それはローカルである必要があり、すべての作業を確実に行うよりも多くの作業が必要になります。顧客のためにそれをインストールしたい時間。

... 今、私はどこにいましたか?

それで、それは私たちをどこに残しますか?簡単です。単一の言語/コード セットをコード ベースとして使用する場合、HTML/CSS/JS は最適な選択肢ではありません...まだです。しかし、彼らはいつかなるかもしれません。現時点では、選択肢はお客様にとって最適と思われるものに限定されています。Java は、リストした安定したオプションですが、明らかに独自の欠点があります。Web が発展するにつれ、新しい機能から多くの非常に優れたものが出てくると思いますが、まだまだ道はあります。

もっと読む:

于 2012-10-23T01:05:30.000 に答える
12

これは可能ですが、間接的に行う必要があります。理論的には、I/O を取得し、ソケットを介して I/O を送信する低レベル言語でソケット サーバーを作成できます (中継だと思います)。HTML5 は、WebSocket または同等のものを使用して、このソケット サーバーと通信します。

于 2012-10-22T23:59:52.600 に答える
1

記録として、2016 年には (chrome 26 以降) うまく機能するが、今後 2 年間で廃止される予定の方法は、html5 を chrome アプリとしてデプロイし、chrome.usb (または chrome.serial または chrome.ブルートゥース)。

私は現在 chrome.usb を使用しており、WebUSB APIを使用して Web アプリに移行することを計画しています(Supersharp の回答を参照)。これは、Google が chrome アプリを廃止するまでに採用されることを願っています。

于 2016-11-16T13:55:21.457 に答える