あなたはどちらの状況にいるか分かっているかもしれません。 または、ビジネスにとって重要なCordovaアプリを引き継ぎ、またはチームが徐々に新しいツールに移行する中で安定したハイブリッドアプリを維持しています。 すると、製品リクエストが届きます。 電話カメラで棚ラベル、チケット、パッケージ、棚タグをスキャンする必要があります。
その時点で バーコードスキャナーモバイルアプリ 仕事が面白くなります。 基本的なデモは簡単です。 製品統合は簡単ではありません。 ハードパートは、バーコード形式をマッチングするプラグインを選択すること、ネイティブパーミッションをきれいに設定すること、実際のデバイスで表示されるプラットフォームのニッチな問題を処理することです。 アプリがフィールドオペレーションやインベントリフローも扱う場合、スキャニング機能は通常、より広範な運用上の懸念と接続されます。 たとえば、 ITの重要なコンポーネントの管理, where the mobile app becomes part of a larger asset and service workflow.
では、モバイルアプリはより大きな資産とサービスフローの一部になります。 cordova create, cordova platform add androidCordovaは、企業のメンテナンス作業でまだ実際のスタックです。 2010年代中盤には、Cordovaでバーコードスキャンはすでに玩具の例からハイブリッド企業アプリに進んでいました。 Androidとバックエンドサービスに接続されたアプリを含み、 barcodeScanner-debug.apk , のドキュメントされたフローを使用し、実際のアプリビルド例から生成された. ごチームも長期的なアーキテクチャの選択肢を比較検討している場合、この ネイティブアプリケーション vs ウェブアプリケーション の比較は、ハイブリッドアプリが本格的なモバイル配信パイプラインに現れる理由を明確にするのに役立ちます。
Table of Contents
- なぜ Cordova アプリにバーコードスキャナーを追加する必要があるか
- Cordova バーコードスキャナー プラグインを選択する
- インストールとプラットフォーム設定
- アプリケーションにスキャナを実装する方法 Code
- テストとトラブルシューティングの一般的なエラー
- パフォーマンスのヒントと Capacitor への移行
バーコードスキャナをCordovaアプリに追加する理由
__CAPGO_KEEP_0__のフィールドで、コルダバアプリの機能を変更するスキャナーが利用できます。ユーザーにシリアル番号、注文ID、製品コードを入力させるのではなく、カメラを入力デバイスとして使用します。これにより、ユーザーが誤った値を入力する方法が減り、操作の抵抗が軽減されます。
実際の運用では、バーコードスキャニングはモバイルアプリと現実の業務の交点で現れます。倉庫受け取り、店舗検索、フィールドサービス部品検証、訪問者チェックイン、内部資産追跡など、すべての機能に利益があります。スキャナーはユーザーの期待も変えます。カメラが利用可能になったら、ユーザーは明確なフォールバックがない限り、手動code入力を許容しなくなります。
コルダバはメンテナンスモードでまだ意味があります。
Cordovaは消えたと言われているが、実際には存在している。多くの企業では、機能が十分に実装されたアプリを置き換えることが困難なため、メンテナンスに多くのリソースを割り当てている。既存のアプリが認証、同期、フォーム、オフラインストレージをサポートしている場合、スキャナ機能を追加することは、全体の製品を再構築するよりもリスクが低いことが多い。
実践ルール: アプリ全体がチームの運用に失敗している場合に限り、スキャニングリクエストをリライトトリガーとして扱わないでください。
Cordovaもその地位を獲得したのは、プラグインがネイティブデバイスの機能をWebcodeが利用できるように公開したからです。 したがって、バーコードスキャニングはハイブリッドモバイルアプリケーションで非常に一般的になりました。 それがCordovaが設計されたパターンに合致しているからです:ネイティブ機能をJavaScriptAPIの背後で実行し、ほとんどのWebベースのアプリのフローを維持します。
ワークフローの中身が価値です。デモだけではありません。
スキャナーボタンのテキストを返すことは簡単です。主な仕事はそれを取り巻くものです:
- サポートされている符号学を選択する: アプリはQRコードのみを必要とするかもしれませんが、レターやロジスティクスコードも必要とするかもしれません。
- 許可をきれいに扱う: カメラへのアクセスが一度失敗すると、ユーザーは機能が壊れたと考えがちです。
- スキャン後のアクションを設計する: 検索、検証、ナビゲーション、重複処理はカメラUIよりも重要です。
- 現代化計画: チームがCapacitorに移行する場合、Cordovaのみの仮定に囚われずに機能するアプローチが必要です。
最後の点は重要です。チームは初期のCordova統合で成功することが多いのですが、ネイティブレンダリングモデルがプラグインの下にある変更によって、移行中にトラブルに直面することがよくあります。スキャナーはまだ機能します。プレビューは期待どおり表示されません。
Cordova バーコード スキャナー プラグインを選択する
Before writing any app code, decide what you’re optimizing for. Some teams need broad barcode support. Others only need a camera overlay for QR flows. Picking the wrong plugin at the start creates rework later, especially when product asks for one more barcode format after launch.
開発者が最も認識するプラグインは cordova-plugin-barcodescanner. Its npm package documents a scan(success, fail) そのプラグインのAPIパッケージは を記載し、QR_CODE、DATA_MATRIX、UPC_A、EAN_13、CODE_128、PDF_417、および AZTECをサポートしています。 plugin package documentation on npm.
プラグイン パッケージ ドキュメントの__CAPGO_KEEP_0__を参照してください。 プラグイン戦略をより広く評価しているチームにとって、このCapacitor プラグインの概要 は役立ちます。 これは、古い Cordova スタイル プラグインの仮定と新しいネイティブ ブリッジ モデルとの違いを強調するためです。
__CAPGO_KEEP_0__をインストールする前に考えるべきことは何ですか
人気だけでは始めないでください。スキャニングジョブから始めましょう。
アプリが複数のバーコードファミリを異なるオペレーショナルコンテキストで読む必要がある場合、広範な符号学的サポートが最小限のAPIよりも重要です。アプリがQRチェックインのみ必要であれば、よりシンプルなカメラエクスペリエンスを提供する限り、狭いツールを受け入れることができます。ジュニア開発者がよく見落とすのは、スキャナー作業は「読めるか」ということではなく、「オペレーションが使用するラベルを読むことができるか」ということです。
適切な選択肢のチェックリストは次のようになります。
- バーコードカバレッジ： 生産環境で使用されている正確な形式を確認すること。
- プラットフォームの期待値： チームが現在まだサポートしているものを確認すること、歴史的にサポートされていたプラグインのものではありません。
- UIモデル： 一部のプラグインはネイティブのスキャナー フローを開きます。 他のプラグインは埋め込まれたプレビュー アプローチを想定します。
- 移行耐性： アプリがCapacitorに移行した場合に、このプラグインが痛みを与える可能性があるかどうかを尋ねてください。
A plugin that works in a demo but fights your app layout, lifecycle, or migration path is usually the wrong plugin.
プラグイン比較表
| 機能 | phonegap-plugin-barcodescanner | cordova-plugin-qrscanner |
|---|---|---|
| 主な用途 | 複数フォーマットのバーコードスキャン | QRに特化したスキャンフロー |
| API スタイル | 多くのレガシーコルダバープロジェクトで多用される、ファミリアークエリーカールバックパターン | ライブカメラプレビュースタイルの使用ケースでよく選択される |
| バーコードフォーマットの範囲 | __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ |
| __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ |
| __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ |
__CAPGO_KEEP_0__
The mistake I see most often is choosing a QR-focused tool because the first release only needs QR, then forcing it into UPC or Code 128 work later. If there’s any chance your business users will scan labels from printers, shelves, bins, or shipping documents, choose for that future now.
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
実装フローは、プラグインまたはSDKを追加し、キャプチャコンテキストを作成し、使用するコードに制限された符号学を絞り込み、UIを構成し、最後にスキャンリスナーを登録することから始まる。 そのシーケンスは、ScanditのCordovaガイドのSparkScanで呼び出され、プロフェッショナルなスキャナーの統合がハイブリッドアプリで維持可能であることを説明しているように、ハイブリッドアプリの開発におけるメンテナンス可能な統合の例です。 ScanditのCordovaバーコードスキャニング開発者ガイドアプリのアーキテクチャレベルがまだ大きくハイブリッドの場合、このガイド Cordovaハイブリッドアプリ開発 は、役立つ相談相手です。
統合フローから始めましょう。
スキャナーフィーチャは、次の項目を決定することでより良くなります。
- アプリが受け入れるバーコードのタイプ。
- スキャンはフルスクリーンアクションか、埋め込まれたワークフローの一部か。
- 成功した読み取り後、アプリが何をするか。
- カメラが使用できない場合のフォールバック。
__CAPGO_KEEP_0__
Cordova インストール手順
一般的なバーコードスキャナープラグインを使用する伝統的なCordova設定の場合、パッケージによって文書化された標準のインストールコマンドから始めます。
cordova plugin add cordova-plugin-barcodescannerプロジェクト設定の典型的なシーケンスは次のようになります。
cordova create barcodeScannerApp
cd barcodeScannerApp
cordova platform add android
cordova platform add ios
cordova plugin add cordova-plugin-barcodescanner
cordova build android
cordova build iosThat sequence is simple, but don’t stop there. Build immediately after plugin installation so you catch native dependency issues before you wire up UI code. If the build fails, solve that first.
ネイティブ設定で通常最初に壊れる設定
iOS カメラアクセスは、ネイティブプロジェクト設定で正しく宣言する必要があります。 許可の使用説明が欠落している場合、または曖昧である場合、スキャナーはユーザーに機能する機能のように振る舞わない可能性があります。 カメラプライバシーの説明を追加してください。カメラが必要な理由を明確に説明する説明が欠落している場合、または曖昧である場合、スキャナーはユーザーに機能する機能のように振る舞わない可能性があります。 Info.plist Android
カメラアクセスは、ネイティブプロジェクト設定で正しく宣言する必要があります。 許可の使用説明が欠落している場合、または曖昧である場合、スキャナーはユーザーに機能する機能のように振る舞わない可能性があります。 カメラプライバシーの説明を追加してください。 カメラアクセスは、ネイティブプロジェクト設定で正しく宣言する必要があります。 許可の使用説明が欠落している場合、または曖昧である場合、スキャナーはユーザーに機能する機能のように振る舞わない可能性があります。 カメラプライバシーの説明を追加してください。インストール後、manifestエントリとプラグイン関連のパーミッションを確認してください。プラグインは必要なものを追加しますが、古いプロジェクトには蓄積された設定変更、カスタムGradle設定、プラグインの重複が原因でビルド警告や実行時混乱が生じることがあります。プラグインが正常にインストールされた場合でも、manifestが綺麗であると仮定するのは危険です。
この簡単なチェックリストを使用してください。
- プラットフォームバージョンを確認してください。 古いCordovaプロジェクトでは、古いプラットフォームパッケージが残っています。
- パーミッションのプロンプトを確認してください。 ユーザーの信頼を維持するために、文言とタイミングが重要です。
- 実機でテストすることを早めに実行してください。 エミュレータではカメラの動作について十分な情報を得られません。
- スキャナーのスコープを狭くしてください。 code のタイプを、ワークフローが受け入れるものだけに有効にします。
スキャナーが1つまたは2つの形式しか必要ない場合、最初にそれらを設定してください。幅広いスキャニングは柔軟性を感じさせますが、デバッグが遅くなるのは、すべての読めないラベルが曖昧になるからです。
ジュニア開発者にとって、重要な教訓は次のとおりです。インストールは単にターミナルコマンドではありません。AndroidとiOSが意図的に設定されていない場合、JavaScript層が救いません。
Implementing the Scanner in Your Application Code
Once the plugin is installed and the app builds, keep the first implementation boring. Put the scan action behind a button, log the full result, and prove the callback flow works before designing a polished UI around it.
The common Cordova scanner pattern uses the plugin’s scan(success, fail) method. That callback style is old, but it’s dependable in legacy codebases and easy to wrap later if your app has moved toward promises or TypeScript abstractions. If you want a clearer mental model for how web code calls native code in these projects, this explanation of how Capacitor bridges web and native code helps, even if you’re still coding in Cordova today.
Plain JavaScript example
Here’s a minimal implementation for an older Cordova app:
<button id="scan-button">Scan barcode</button>
<div id="scan-result"></div>document.addEventListener('deviceready', function () {
var button = document.getElementById('scan-button');
var resultEl = document.getElementById('scan-result');
button.addEventListener('click', function () {
cordova.plugins.barcodeScanner.scan(
function (result) {
if (result.cancelled) {
resultEl.textContent = 'Scan cancelled';
return;
}
resultEl.textContent =
'Text: ' + result.text +
' | Format: ' + result.format;
},
function (error) {
resultEl.textContent = 'Scan failed: ' + error;
}
);
});
});This does three useful things. It waits for deviceready, binds scanning to an intentional user action, and handles both success and failure explicitly. Don’t skip the cancelled case. Users back out of camera flows all the time.
TypeScript example
TypeScriptを使用するプロジェクトの場合、結果の形状を定義して、残りのアプリがきれいに消費できるようにします:
interface BarcodeScanResult {
text: string;
format: string;
cancelled: boolean;
}
function scanBarcode(): void {
cordova.plugins.barcodeScanner.scan(
(result: BarcodeScanResult) => {
if (result.cancelled) {
renderStatus('Scan cancelled');
return;
}
handleScannedCode(result);
},
(error: unknown) => {
renderStatus(`Scan failed: ${String(error)}`);
}
);
}
function handleScannedCode(result: BarcodeScanResult): void {
renderStatus(`Scanned ${result.format}: ${result.text}`);
if (!result.text) {
renderStatus('Empty scan result');
return;
}
lookupItemByCode(result.text);
}
function renderStatus(message: string): void {
const el = document.getElementById('scan-result');
if (el) el.textContent = message;
}
function lookupItemByCode(code: string): void {
console.log('Lookup code:', code);
}このバージョンではスキャンとビジネスロジックを分離しています。それが重要な理由です。スキャナープラグインは、入力のみをキャプチャするようにすべきだからです。検証、検索、ナビゲーションは他の場所に属するものです。
スキャン結果の処理
通常、スキャン後のフローは次のいずれかです:
- 検索フロー: スキャナーテキストを使用して、製品、注文、または資産レコードを取得します。
- 検証フロー: スキャナードキュメントを既に表示されているcodeと比較します。
- ナビゲーションフロー: スキャナードキュメントに関連付けられたタスクにユーザーをルーティングします。
- キャプチャフロー: スキャナードキュメントをローカルに保存して、後で同期する準備をします。
スキャナーのコールバックが API の呼び出し、DOM の更新、分析、ナビゲーションに使われるのを避けよう。
また、テストの初期段階で、raw の結果をログに残しておくこともおすすめです。生産用の UI が __CAPGO_KEEP_0__ を必要としている場合でも。 text、返された format code のスキャン結果が正しくない場合に役立ちます。オペレーションが “この code を読むことができない” と言う場合、フォーマットデータは、バーコードのタイプが問題であるか、バーコードの品質が問題であるかを判断するのに役立ちます。
一般的なエラーのテストとトラブルシューティング
ほとんどの Cordova のバーコード スキャナーの問題は、スキャン API 自体ではなく、ウェブ UI、ネイティブ ビュー、デバイスのパーミッションの境界から生じています。
The hardest issue to diagnose is the Android rendering bug that shows up during Capacitor migrations or mixed Cordova-Capacitor setups. A developer in Capacitor issue #1213 described it plainly: 最も難しい問題は、Android のレンダリングのバグです。このバグは、capacitor のマイグレーション中や、Cordova と __CAPGO_KEEP_1__ の混合セットアップ中に出現します。開発者が __CAPGO_KEEP_2__ の issue #1213 で説明したように、簡潔に説明しました。 “私の Capacitor アプリでこのプラグインを試したが、スキャナーはアプリの後ろに隠れているように見えます”、そして、ネイティブのウェブビューの背景を透明にし、DOM の透明性の変更を合わせることで修正する必要があります。この修正は、標準の Cordova のチュートリアルがカバーしていないことが多く、__CAPGO_KEEP_0__ の Android レンダリングの問題の議論で文書化されています。 ハイブリッドのマイグレーションをデバッグしている場合、この Capacitor アプリのデバッグのガイドを参照してください __CAPGO_KEEP_0__
アプリのバグの背後にあるAndroidのプレビュー
症状
スキャナーを起動します。パーミッションは正常です。明らかなクラッシュはありません。ただし、カメラのプレビューは、UIの後ろに隠れ、ブロックされ、または「後ろ」に表示されます。
原因
ネイティブのスキャナー ビューとウェブ ビューは、元の Cordova プラグインが想定していたレイヤー構造と異なります。Android の Capacitor-style セットアップでは、ウェブ ビューの背景が不透明のままになることがあります。したがって、ネイティブのプレビューは存在しますが、ウェブ ビューの背景の下に隠れます。
解決策
両方の側面に透明なビュー設定を適用します。
- ネイティブ側: ウェブ ビューの背景を透明に設定します。
- ウェブ側: スキャナー プレビューの上に座っているコンテナ要素から不透明な背景を削除します。
- Layout side: デフォルトの背景色を確認するには、フルスクリーンラッパー、モーダルシェル、フレームワークページコンテナを確認してください。
- Testing side: 実機のAndroidデバイスでテストすることによって、開発シェルのレイアウトの挙動が誤解を招く可能性があるため、物理的なデバイスで検証してください。
この問題は、実際にはビューの組み立て問題であるのに、プラグインが壊れていると開発者が思うように見える問題です。
許可の失敗と誤判
許可が失敗すると、スキャナーのバグのように見えることがあります。
ユーザーがカメラへのアクセスを拒否した場合、コールバックは一般的なエラーを表面化するか、スキャナーが期待どおりに表示されない可能性があります。許可の拒否をUIの通常のbranchとして扱い、ユーザーに何が起こったかと再接続する方法を伝えましょう。iOSでは、不明瞭な許可のテキストは、ユーザーがスキャナーを表示する前に不信感を生み出します。
いくつかの習慣が役立ちます:
- 明確なユーザーアクションでスキャンをトリガーすること: 許可の求め方は疑わしいように思われません。
- フォールバック入力を表示すること: 手動入力はワークフローを維持する。
- テストを拒否し、再試行パス: 多くのチームは、ハッピーパスを一度だけテストします。
プラグインのインストール後にビルドとデバイステストの問題
特定の環境でのみ表示される失敗もある。
| 問題 | 可能性のある原因 | 実用的な修正 |
|---|---|---|
| スキャナーが開かれるが、有用な結果は返されない | サポートされていないまたは予期しないバーコード形式 | 既知のラベルでテストして、構成済みのケースに合わせます。 |
| プラグインのインストール後にビルドが破損する | 古いプロジェクトでプラットフォームまたは依存性のドリフト | アプリの code の前にプラットフォームパッケージを整理する |
| 1 つのアプリシェルで動作するが、別のアプリシェルでは動作しない | ビュー層化またはCSSの干渉 | 画面を最小限のレイアウトに削ぎ、スタイルを徐々に追加する |
| エミュレータの動作は誤解を招く | カメラのシミュレーションは実際のデバイスの現実を反映していない | 物理的なAndroidとiPhoneハードウェアでテストする |
画面を1つのボタンと1つの結果要素に削ぎ、デバッグする。スキャナがそこで動作する場合、問題は通常レイアウトまたはアプリシェル code であってプラグインではありません。
パフォーマンスのヒントと Capacitor への移行
バーコードスキャナーは正しくデコードできても、実際にはユーザーに失敗することがある。問題は通常、遅延、フリッカー、カメラプレビューの不具合、またはAndroidの画面が同じテストプールの異なるデバイス間で異なる挙動を示すことである。
古いCordovaアプリでは、デコーダーが弱点であることが多い。ウェブビュー、ビュー層化、 code がスキャン結果に反応することが、バーコード認識自体よりも多くのトラブルを引き起こすことが多い
__CAPGO_KEEP_0__。スキャン画面の範囲を狭くしてください。品目ラベルをスキャンする画面なら品目ラベルをスキャンしてください。余分なフィルターやアニメーションパネル、画面の状態の広範な更新は、すでにAndroid WebViewのレンダリングが脆弱なところで再描画の作業を増やします。
__CAPGO_KEEP_0__。いくつかの変更が速く効果を発揮します：
- __CAPGO_KEEP_0__。受け入れるバーコード形式を制限します。プラグインがサポートする場合は、偽読を減らし、テストカバレッジを簡単に推論できるようにします。 __CAPGO_KEEP_0__。スキャン後のロジックを短くします。
- __CAPGO_KEEP_0__。UIの最小限の部分をパース、検証、更新します。 __CAPGO_KEEP_0__。一時的に重複読み取りをブロックします。
- __CAPGO_KEEP_0__。一部のデバイスでは、ユーザーがカメラを動かすまで同じ結果を複数回発火します。 __CAPGO_KEEP_0__。手動入力が流れの中に組み込まれるように設計します。
- __CAPGO_KEEP_0__。実際の環境では、損傷したラベル、悪い照明、反射的なパッケージングが発生する可能性があります。 __CAPGO_KEEP_0__。Androidの再描画コストを注意深く監視します。
- __CAPGO_KEEP_0__。重いオーバーレイ、CSSトランジション、層化されたコンポーネントは、Cordova WebView内でカメラプレビューを不安定にします。 __CAPGO_KEEP_0__。
Capacitorへの実用的な移行パス
CordovaからCapacitorへのクリーンな移行は、ステージング、ではなく、英雄的なものではありません。チームがアプリコンテナ、スキャナープラグイン、パーミッションフロー、UIオーバーレイを一度に置き換えると、問題が生じて、どの変更が原因であるかを判断できなくなります。
この順序を使用するのではなく:
-
現在のプラグインを検査する
すべてのCordovaプラグインをリストし、それぞれをアクティブ、置き換え可能、またはリスクがあるものとしてマークし、それが古いプラットフォームの動作に依存している場合を含む。 -
アプリシェルを最初に移動する
Capacitor内で既存のWebアプリを実行し、スキャナをcodeに置き換えるのではなく、コンテナの問題とプラグインの問題を分離する。 -
Cordovaプラグインを短期間必要に応じて保持する
一時的な互換性は、同時にスキャナ、ファイルアクセス、パーミッションハンドリングを書き直すのではなく、安全であることがよくあります。 -
脆弱なスキャナーペースを早期に置き換える
カスタムオーバーレイ、未文書化のAndroid動作、または古いカメラハンドリングに依存する古いプラグインは、優先順位の高い順に置き換える必要があります。
Androidカメラプレビューのバグは特別な注意が必要です。大量のデバッグ時間を浪費するからです。私は、ネイティブプレビューがウェブビューの後ろに隠れ、エッジでクリップされる、あるいは特定のAndroidデバイスで黒く表示されるケースを何度も見てきました。
その時点で、バーコードプラグインが最初に非難されることが多いのですが、実際にはビューの組み合わせが根本的な問題だからです。
This is also where a migration to Capacitor starts to justify itself. Capacitor does not remove every camera bug, but it usually gives you a cleaner boundary between native view handling and web UI code. For barcode scanning, この時点で、capgoへの移行が自分自身を正当化するようになります。__CAPGO_KEEP_1__はすべてのカメラバグをなくしませんが、通常はネイティブビューのハンドリングとWebUIの境界をきれいに分離することができます。 @__CAPGO_KEEP_0__/camera-preview @capgo/capacitor-zebra-datawedge Zebraデバイスのエンタープライズスキャニング用に @capgo/capacitor-zebra-datawedge DataWedgeプロファイルとスキャントリガーを管理します。NFCタグワークフロー用に、
Cordovaプロジェクトはプラグインの古さ、プラットフォームのずれ、古い統合内の隠れた仮定によって破壊される傾向があります。 Capacitor プロジェクトは、ライフサイクルハンドリングとネイティブレイヤーに関連する異なる問題を露出しますが、ネイティブ側が明示的であるため、エラーはより簡単に追跡できます。
Cordovaスキャナが現在機能するのは、デバイス固有の修正のスタックに依存している場合、修正を追加するのをやめましょう。 スキャン画面を安定させ、Androidプレビューのバグが本当にウェブビュー層化問題であるかを確認し、次に制御されたステップで移行しましょう。 そのパスは、1週間で遅く、プロジェクトの残りの部分では速くなります。
