バーコードプラグイン

あなたは、どちらの状況にいるか分からないかもしれません。または、ビジネスにとって重要なコルバックアプリを引き継ぎました、または、チームは徐々に新しいツールに移行しながら、安定したハイブリッドアプリを維持しています。すると、製品リクエストが来ます: スマホカメラで棚札、チケット、パッケージ、棚札をスキャンする必要があります。

その時は バーコードスキャナ 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 Cloudflare 、および生成されたSitePointのCordovaスキャニングウォークスルーから実際のアプリビルド例です。チームが長期的なアーキテクチャの選択肢を比較検討している場合、この

ネイティブアプリケーション vs ウェブアプリケーション

バーコードスキャナをCordovaアプリに追加する理由
- Cordovaはメンテナンスモードでもまだ意味があります
- ワークフローが価値を持ち、デモではありません
Cordovaのバーコードスキャナプラグインを選択する
- 何が重要なのか、インストールする前に
- プラグイン比較表
インストールとプラットフォーム設定
アプリケーションにスキャナを実装する Code
一般的なエラーのテストとトラブルシューティング
Capacitorへのパフォーマンスの改善と移行
- Capacitorへの実用的な移行

Cordovaアプリにバーコードスキャナーを追加する理由

バーコードスキャナーは、ユーザーがシリアル番号、注文ID、製品コードを手動で入力するのではなく、カメラを入力デバイスとして使用できるようにするため、アプリの機能を変える

In practice, barcode scanning shows up where mobile apps meet real operations. Warehouse receiving, retail lookup, field service parts validation, visitor check-in, and internal asset tracking all benefit from it. A scanner also changes user expectations. Once the camera is available, users stop tolerating manual code entry unless there’s a clear fallback.

倉庫受け取り、店舗検索、フィールドサービス部品検証、訪問者登録、内部資産追跡など、すべてがこれに利益を得る

多くのチームはCordovaについて話していますが、消えたように思うかもしれません。実際には、メンテナンスが重いエンタープライズポータフォリオに成長しました。機能するアプリを置き換えることよりも拡張する方が難しいです。既存のアプリが認証、同期、フォーム、オフラインストレージをサポートしている場合、スキャナを追加することは、全体の製品を再構築することよりもリスクが低くなります。

実用的なルール: スキャニングリクエストをリライトトリガーとして扱うことは、残りのアプリがチームの運用に失敗している場合に限ります。

Cordovaは、プラグインがネイティブデバイスの機能をウェブcodeが利用できるようにしたため、そこに位置を獲得しました。そのため、バーコードスキャニングはハイブリッドモバイルアプリで非常に一般的になりました。Cordovaは、主にウェブベースのアプリフローを維持しながら、ネイティブ機能をJavaScriptAPIの背後で実行できるように設計されました。

ワークフローの中身が価値であり、デモだけではありません。

テキストを返すスキャナーボタンは簡単な部分です。主な仕事はそれらを取り巻くものです:

サポートされている符号体系を選択する: アプリはQRコードのみを必要とするかもしれませんが、レターやロジスティクスコードも必要とするかもしれません。
許可をきれいに扱う: カメラアクセスが一度失敗すると、ユーザーは機能が壊れたと考えがちです。
スキャン後のアクションを設計する: 検索、検証、ナビゲーション、重複処理はカメラUIよりも重要です。
現代化計画： チームがCapacitorに移行する場合、Cordovaのみの仮定に特性を閉じ込めるアプローチは必要ありません。

最後の点は重要です。チームは初期のCordova統合で成功し、移行中にトラブルに直面します。プラグインの下でネイティブレンダリングモデルが変更されているためです。スキャナーはまだ機能しています。プレビューは期待どおり表示されません。

Cordova バーコードスキャナープラグインの選択

アプリをcodeする前に、どの機能を最適化するかを決定する必要があります。チームは広範なバーコードサポートが必要な場合もあります。他方はQRフロー用にカメラオーバーレイのみが必要な場合もあります。最初に間違ったプラグインを選択すると、後でリワークが必要になります。特に、製品がリリース後に1つ以上のバーコード形式を要求した場合です。

開発者が最も認識するプラグインは cordova-plugin-barcodescannerプラグインのnpmパッケージは scan(success, fail) APIと、QR_API、DATA_MATRIX、UPC_A、EAN_13、__CAPGO_KEEP_1___128、PDF_417、AZTECなどの一般的な符号化方式のサポート QR_CODE, DATA_MATRIX, UPC_A, EAN_13, CODE_128, PDF_417, and AZTECプラグインパッケージドキュメントの__CAPGO_KEEP_0__ より広くプラグイン戦略を評価するチームのために、このnpmの概要.

__CAPGO_KEEP_0__ Capacitor プラグインについて知っておくべきこと __CAPGO_KEEP_0__ は便利です。なぜなら、古い Cordova スタイルのプラグインの仮定と新しいネイティブブリッジモデルとの差異を強調するからです。

Cordova プラグイン - cszbar と PhoneGap プラグイン - barcodescanner の機能の比較表

インストールする前に気をつけるべきことは

人気だけでは始めないでください。スキャニングジョブから始めましょう。

アプリが複数のバーコードファミリーを異なるオペレーショナルコンテキストで読み取る必要がある場合、広範な符号学的サポートは最小限の API よりも重要です。アプリが QR チェックインのみ必要な場合、シンプルなカメラエクスペリエンスを提供する限られたツールを受け入れることができます。

新人開発者がよく見落とすのは、スキャナー作業は「読み取ることができるか」ということではなく、「オペレーションが使用するラベルを読み取ることができるか」ということです。

適切な選択チェックリストは次のようになります。 バーコードカバレッジ：
生産環境で使用されている正確な形式を確認すること。 プラットフォームの期待値：
チームが現在まだサポートしているもの、歴史的にサポートしていたものとは異なるものを確認すること。 ネイティブスキャナーフローを開くプラグインもあります。Embedded プレビューアプローチを想定するプラグインもあります。
移行耐性: Capacitor にアプリを移行した場合、このプラグインはどれくらいの苦労になるかを尋ねます。

デモで動作するプラグインがアプリのレイアウト、ライフサイクル、または移行パスと戦う場合、そのプラグインは通常間違っているプラグインです。

プラグイン比較表

機能	phonegap-plugin-barcodescanner	cordova-plugin-qrscanner
主な用途	複数の形式のバーコードスキャニングを幅広くサポート	QR フォーカススキャニングフロー
API スタイル	多くの古典的なCordovaプロジェクトで見られる、慣れ親しみのコールバックパターン	ライブカメラプレビュースタイルの使用ケースでよく選択される
バーコード形式の範囲	QR以外の製品要件が必要な場合に適合する	QRが唯一の厳密な要件の場合に適合する
移行リスク	古い仮定が現れる可能性があるため、現代のブリッジ移行では機能する可能性があります	プレビュー重視のアプローチは、レンダリング問題を早期に暴露する可能性があります
最適な選択	小売、物流、資産、混合バーコードワークフロー	チェックイン、URL、認証、QRのみのフロー

表は実用的な適合度を反映しており、スコアカードではありません。小売および物流シンボロジーが必要な場合は、より広範なプラグインカテゴリが通常は安全な選択肢です。ただし、QRのみをスキャンし、より制御されたプレビュー体験を必要とする場合は、QRに特化したパスがスリムになる可能性があります。

最もよく見るミスは、最初のリリースにQRのみをサポートするツールを選択し、その後UPCまたはCode 128の機能を強制することです。ビジネスユーザーがラベルをプリンター、棚、ボックス、または発送書類からスキャンする可能性がある場合、その将来のために今すぐ選択してください。

インストールとプラットフォームの設定

統合は最初のスキャン前に破損することが多く、JavaScriptの期待とネイティブプラットフォームの設定の間の設定のずれが最も多く原因となっています。この部分をチェックリストとして扱い、速いインストールではありません。

実装フローは、プラグインまたはSDKを追加し、キャプチャコンテキストを作成し、生産で使用するコードに制限された符号ロジーを絞り込み、UIを構成し、最後にスキャンリスナーを登録することから始まります。このシーケンスは、ScanditのCordovaガイドのSparkScanの部分に記載されており、プロフェッショナルなスキャナーの統合がハイブリッドアプリで維持可能であることを説明しているCordovaの開発者ガイドの部分と一致しています。 ScanditのCordova バーコードスキャニング開発者ガイド. If your app is still heavily hybrid at the architecture level, this guide to Cordovaハイブリッドアプリ開発ガイド is a helpful companion.

コンピューターとcodeエディター、モバイルフォンを立てて、木の台に回路板を置いた写真です。

統合フローから始めましょう。

スキャナーフィーチャは、次のアイテムを決定することから始めると、より良くなります。

アプリが受け入れるバーコードのタイプを選択することです。
全画面アクションか、埋め込まれたワークフローの一部か。
読み取りが成功した後、どのようなアプリの動作が必要か。
カメラが使用できない場合のフォールバックが存在するか。

プラグインのインストールが実際のワークフローとデバイスの一般的な機能に結びついているか。

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 ios

That 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 カメラアクセスは、ネイティブプロジェクトの設定で正しく宣言されている必要があります。許可の使用説明が欠落している場合、または曖昧である場合、スキャナーはユーザーに機能する機能のように動作しない可能性があります。カメラプライバシーの説明を明確に追加してください。On Info.plist __CAPGO_KEEP_0__

アプリがカメラを使用する必要がある理由について説明します。 OnAndroid

インストール後、レビューマニフェストエントリとプラグイン関連のパーミッション。プラグインは必要なものを追加するかもしれませんが、古いプロジェクトには蓄積された構成変更、カスタム Gradle 設定、またはプラグインのオーバーレイが原因でビルド警告または実行時混乱が生じることがあります。プラグインが正常にインストールされたら、マニフェストが綺麗であると仮定してはいけません。

このクイックチェックリストを使用します。 プラットフォームバージョンを確認します。
古い Cordova プロジェクトには古いプラットフォームパッケージが含まれていることがあります。 許可の求め方をレビューします。
ユーザーの信頼を維持するために、言葉とタイミングが重要です。 実機で早期にテストします。
エミュレータではカメラの動作について十分な情報を得られません。 codeを使用するタイプは、ワークフローが受け入れるものに限ります。

スキャナーが1つまたは2つのフォーマットしか必要としない場合、まずそれらを設定してください。幅広いスキャニングは柔軟性を感じさせますが、実際には、読めないラベルが曖昧になるため、デバッグが遅くなることがよくあります。

ジュニア開発者にとっての重要な教訓は、このことです：インストールは単にターミナルコマンドではありません。AndroidとiOSは意図的に設定されていなければなりません。JavaScript層は、AndroidとiOSが意図的に設定されていない場合でも、開発者を救うことはできません。

アプリケーションにスキャナを実装する方法Code

プラグインがインストールされ、ビルドが完了したら、最初の実装は単純にしましょう。スキャンアクションはボタンに置き、フル結果をログし、コールバックフローが機能することを証明する前に、ポリッシュされたUIを設計するのを待ってください。

Cordovaスキャナーパターンは、プラグインの"method"を使用します。その呼び出しスタイルは古いですが、レガシーコードベースで依然として信頼できるものです。また、PromiseやTypeScriptアブストラクションに移行したアプリに簡単にラップできるため、依然として便利です。Web __CAPGO_KEEP_0__がネイティブ __CAPGO_KEEP_1__を呼び出すしくみを明確に理解したい場合は、この説明が役立ちます。Webとネイティブを結ぶ__CAPGO_KEEP_0__のしくみは、Cordovaでまだコードを書いている場合でも役立ちます。 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 古いCordovaアプリ用の最小限の実装

__CAPGO_KEEP_1__

__CAPGO_KEEP_0__

<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、スキャンを意図的に行うユーザーアクションにバインドし、成功と失敗を明示的に処理します。キャンセルされた場合を省略しないでください。ユーザーはカメラフローから常に退出します。

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 更新、分析、ナビゲーションに使うのを避けましょう。値を早く渡します。

また、テストの初期段階でロギングを実行してください。生産用 UI が必要とするのは「」だけですが、返された値はデバッグに役立ちます。ラベルが一致しない場合に、ラベルが一致しないことを示すために便利です。オペレーションが「スキャナーがこの __CAPGO_KEEP_0__ を読めない」という場合、フォーマットデータは、バーコードのタイプが問題であるか、バーコードの品質が問題であるかを判断するのに役立ちます。 textテストとトラブルシューティングの一般的なエラー format ほとんどのバーコードスキャナー Cordova の問題は、スキャン code 自身ではなく、Web UI、ネイティブビュー、デバイスパーミッションの境界から来ています。ここでは、クリーンなデモが混乱したバグレポートに変わります。

最も診断が難しい問題は、Android レンダリングバグです。このバグは、__CAPGO_KEEP_0 マイグレーション中や、Cordova と CAPGO_KEEP_1 の混合セットアップ時に発生します。開発者は CAPGO_KEEP_2__ の issue #1213 で明確に説明しました。

「私の API アプリでこのプラグインを試しましたが、スキャナーはアプリの後ろにあります」というのは、開発者が説明したものです。

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: capacitor__CAPGO_KEEP_1__ Capacitor AndroidRenderingIssueAndroidアプリのデバッグを行っている場合、この Capacitorアプリのデバッグのためのこのガイドを

常に開いておくとよいでしょう。

Androidアプリのプレビューが表示されない
症状

スキャナーを起動します。パーミッションは正常です。明らかなクラッシュは発生しません。ただし、カメラプレビューは表示されません、または「後ろ」に隠れています。
The native scanner view and the webview are layered differently than the original Cordova plugin expected. On Android in Capacitor-style setups, the webview background can remain opaque, so the native preview exists but stays hidden beneath it.

ネイティブのスキャナービューとウェブビューは、元の Cordova プラグインが想定していたようにレイヤー化されていません。Androidで__CAPGO_KEEP_0__スタイルの設定を使用している場合、ウェブビューの背景は不透明のままになり、ネイティブのプレビューは存在しますが、ウェブビューの背景の下に隠れています。
解決策

両方の側面に透明なビューの設定を適用します。 ウェブビューの背景を透明に設定します。
Web側: スキャナープレビュー上に座っているコンテナ要素から不透明背景を削除します。
レイアウト側: デフォルトの背景色を検証するには、フルスクリーンラッパー、モーダルシェル、フレームワークページコンテナを確認します。
テスト側: 開発シェルではレイアウトの動作が誤解を招く可能性があるため、物理的なAndroidデバイスで検証します。

このバグは、実際にはビューの組み合わせ問題であるのに、開発者がプラグインが機能しないように思わせるものです。

許可の失敗と誤った否定

許可が失敗すると、スキャナーバグのように見える可能性があります。

ユーザーがカメラへのアクセスを拒否した場合、コールバックは一般的なエラーを表面化するか、スキャナーが予期しないように表示される可能性があります。許可の拒否をUIの通常のブランチとして扱い、ユーザーに何が起こったかと再接続する方法を伝えましょう。特にiOSでは、不明瞭な許可テキストはユーザーがスキャナーを表示する前に不信感を生み出します。

いくつかの習慣が役立ちます:

__CAPGO_KEEP_0__からクリアなユーザーアクションでスキャンをトリガーする: 許可のプロンプトは疑わしいように思われない。
フォールバック入力を表示する: 手動入力はワークフローを維持する。
拒否をテストし、再試行パスをテストする: 多くのチームは、ハッピーパスを一度だけテストする。

ビルドとデバイスのテスト問題

特定の環境でのみ表示される失敗

問題	原因	実用的な修正
スキャナーが開かれるが、有用な結果は返されない	非対応または予期せぬバーコード形式	既知のラベルで構成されたテストケースで確認してください。使用するケースに合わせて設定されているものと一致するもの
プラグインのインストール後にビルドが破綻する	古いプロジェクトでプラットフォームまたは依存関係のズレが発生する	codeのアプリを変更する前にプラットフォームパッケージを整合させる
1つのアプリシェルで動作するが、別のアプリシェルでは動作しない	ビューのレイヤーングまたはCSSの干渉	画面を最小限のレイアウトに戻し、スタイルを徐々に追加してみる
エミュレータの動作は誤解を招く	デバイスの現実世界のカメラシミュレーションは反映されない	物理的なAndroidとiPhoneハードウェアでテストすることを早期に実施する

デバッグ中にスキャナーが動作する場合、問題は通常レイアウトまたはアプリシェルcodeではなくプラグインではありません。ページを1つのボタンと1つの結果要素に削減してみる

パフォーマンスのヒントとCapacitorへの移行

実際にはユーザーに失敗する可能性があるバーコードスキャナーは正しくデコードできます。問題は通常、遅延、フリッカー、カメラプレビューの不具合、または同じテストプールから同じデバイスで異なるAndroid画面の挙動として現れます。

古いCordovaアプリでは、デコード器はしばしば弱点ではありません。ウェブビュー、ビューのレイヤーング、codeがスキャン結果に反応する部分が、バーコード認識自体よりも多くのトラブルを引き起こします。

スキャン画面を狭くすることから始めましょう。スキャンするのは棚札のラベルだけなら、棚札のラベルだけをスキャンするようにします。余分なフィルタ、アニメーションパネル、広範な状態の更新は、すでにAndroidウェブビューのレンダリングが脆弱なところで再描画の作業を増やします。

いくつかの変更が速く効果を発揮します:

受け入れるバーコード形式を制限します。プラグインがサポートしている場合、間違った読み取りを減らし、テストカバレッジを簡単に推論できるようにします。後処理のロジックを短くします。
UIの最小限の部分を解析、検証、更新します。 一時的に重複読み取りをブロックします。
いくつかのデバイスは、ユーザーがカメラを動かすまで同じ結果を複数回発火します。 手動入力をフローに組み込んでください。
__CAPGO_KEEP_0__ 実際の環境ではラベルが損傷したり、照明が悪かったり、パッケージが反射したりすることがまだあります。
Androidの再描画コストをよく見てください。 重いオーバーレイ、CSSトランジション、レイヤードコンポーネントは、CordovaのWebビュー内でカメラプレビューを不安定にします。

モバイルバーコードスキャナーアプリケーションの最適化と将来の保証のプロセスを示す4ステップのインフォグラフィック。

実用的なCapacitorへの移行のパス

最も綺麗なCordovaからCapacitorへの移行は、ステージング、ではなく、英雄的なものではありません。チームがアプリコンテナ、スキャナープラグイン、パーミッションフロー、UIオーバーレイを一度に置き換えると、原因を特定できなくなります。

この順序を使用するのではなく:

現在のプラグインを検査する
すべてのCordovaプラグインをリストし、それぞれをアクティブ、置き換え可能、またはリスクのあるものとしてマークし、それが古いプラットフォームの動作に依存している場合。
アプリシェルを最初に移動する
既存のWebアプリをCapacitor内で実行し、スキャナcodeを置き換える前に、コンテナの問題とプラグインの問題を分離する。
必要に応じて短期間Cordovaプラグインを維持する
一時的な互換性は、同時にスキャナ、ファイルアクセス、パーミッションハンドリングを書き直すよりも安全であることがよくあります。
脆弱なスキャナの部分を早期に置き換えます。
古いプラグインがカスタムオーバーレイ、未文書化のAndroid動作、または古いカメラハンドリングに依存している場合は、優先順位の高いリストに配置する必要があります。

Androidカメラプレビューのバグには特別な注意が必要です。なぜなら、デバッグ時間を浪費するからです。私は、ネイティブプレビューがウェブビューの後ろに隠れ、エッジでクリップされる、または特定のAndroidデバイスで黒く表示される場合、スキャナ画面が失敗することがあります。その時点で、バーコードプラグインが最初に非難されることがあります。ただし、ビューの組み合わせが根本的な問題であることが多いです。

その場合は、レンダリングの調査としてではなく、スキャナの調査として扱うべきです。装飾的なオーバーレイを削除し、プレビュー、1つのトリガー、1つの結果フィールドにページを簡素化します。プレビューが安定したら、問題は通常、画面構造またはCSSにあります。デコードではありません。

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/camera-preview @__CAPGO_KEEP_0__/camera-preview @capgo/capacitor-zebra-datawedge Zebraデバイスのエンタープライズスキャニングの場合、 @capgo/capacitor-zebra-datawedge、 iOSとAndroidでnativeタグの検出、読み取り、書き込みを管理する。

Cordovaプロジェクトはプラグインの古さ、プラットフォームのズレ、古い統合内の隠れた仮定によって破壊される傾向があります。 Capacitor プロジェクトでは、ライフサイクルハンドリングとネイティブレイヤーの問題が主に発生しますが、ネイティブ側が明示的であるため、エラーのトレースが容易です。

現在のCordovaスキャナがデバイス固有の修正のスタック後にのみ機能する場合、修正を追加するのをやめましょう。スキャン画面を安定させ、Androidプレビューのバグが本当にウェブビューのレイヤリング問題であるかを確認し、次に制御されたステップで移行することを検討してください。そのパスは1週間で遅いですが、プロジェクトの残りの部分では速くなります。

2026年バーコードスキャナーコルバックアプリの作成