SDK をインストールする
アプリのディレクトリで両方のパッケージをインストールします。アプリの React と React Native の依存関係はそのままにします。プロジェクトの SDK キーを作成する
アプリには、プロジェクト単位の書き込み専用 SDK キーを渡します。Expo はEXPO_PUBLIC_* の値をすべてアプリのバンドルに含めます。この変数にアカウントやサーバーの認証情報を入れないでください。
CLI v0.1.32 以降では、既存のプロジェクトにキーを作成できます。新しいプロジェクトは作成しません。プロジェクト ID を確認します。
--abandon-retry は使わないでください。
キーのファイルはソース管理に含めないでください。CLI を認可したアカウントの認証情報は使わないでください。Expo のローカル開発では、アプリのルートにある、無視対象の .env.local ファイルにキーを入れます。
process.env.EXPO_PUBLIC_LOGBREW_CLIENT_KEY を直接参照する形のままにします。値を変えた後は、アプリを完全に再読み込みします。ビルド時の設定については Expo の環境変数を参照してください。Expo を使わない React Native アプリでは、代わりにアプリ独自の設定でキーを読み込みます。
クライアントを作成する
この設定は、アプリが起動時に読み込む1つのモジュールに置きます。レンダリングのたびにクライアントを作らないでください。サービス、環境、リリースはcontext に入れます。
stopAppStateListener() を呼び出します。
ネイティブのキューでは、1つのキーを使える有効なクライアントは1つだけです。同じキーで2つ目のクライアントを作ると、configuration_error で失敗します。これも、クライアントを1回だけ作る理由の1つです。
テストログを送信して見つける
開発時だけのテスト操作から、verifyLogBrewSetup() を1回呼び出します。結果を await し、拒否された Promise を処理します。キーやイベントのバッチを出力しないでください。
結果が 2xx で batches が0より大きければ、LogBrew がバッチを受け付けたことを示します。自動送信が先にイベントを送ることがあるため、空のフラッシュは試行0回、バッチ0件で 204 を返します。どちらの場合も、保存されたログを CLI で読みます。
RecordingTransport.alwaysAccept() はローカルのテスト専用です。合成の 202 を返し、リクエストは送信しません。
オフライン時と再起動後の送信
実行中のアプリでclient.deliveryHealth().storage を読みます。
persistent:クライアントはネイティブのキューを使っています。保留中のイベントは、アプリを再起動した後に再び読み込まれます。memory:JavaScript ランタイムが再起動すると、保留中のイベントは失われます。
persistentQueue: "auto" は、アプリのバイナリに LogBrew のネイティブモジュールが含まれている場合にネイティブのキューを使います。Expo Go と古いバイナリはメモリを使います。JavaScript だけの更新では、ネイティブモジュールを追加できません。
本番環境のアプリで再起動後の送信が必要な場合は、persistentQueue: "required" を設定します。この場合、ネイティブのキューがないとクライアントの作成が configuration_error で失敗します。ネイティブモジュールを含めてアプリをビルドし直してください。persistentQueue: "disabled" は、メモリのキューを使いたい場合だけ使います。
ネイティブのキューに保持できるのは、最大1,000件のイベントと4 MiB のイベントデータです。クライアント側の上限がそれより小さい場合は、そちらも適用されます。ネイティブのキューにあるイベントは、再起動後もイベント ID を保持します。
送信は少なくとも1回(at-least-once)なので、再試行でイベントが2回送られることがあります。イベント ID と内容が、LogBrew がすでに受け付けたイベントと一致する場合、LogBrew はそれを再び保存しません。バックグラウンドのフラッシュは試行であり、送信できたことの証明ではありません。オフライン時の取得とアプリの再起動をテストしてください。そのうえで、保存されたイベントをプロジェクトで探します。
送信の状態を読む
client.deliveryHealth() は、イベントの内容を含めずに、キューと送信の状態を返します。まず次のフィールドを読みます。
ログの内容を決める
各メッセージは短く具体的にします。リクエストの失敗や再試行の予定など、アプリで起きた結果を書きます。氏名、メールアドレス、アクセストークン、フォームの値、リクエストボディを含めないでください。 イベントに合った重大度を使います。info、warning、error、critical のいずれかです。関連する記録を見つけられるように、サービス、環境、リリースは一貫させます。
npx react-native log-ios と npx react-native log-android は、ローカルのデバイスのログを表示します。LogBrew には問い合わせません。React Native のネイティブのデバッグを参照してください。
確認が失敗したときに回復する
flush() が失敗すると、SDK のエラーコードで拒否されます。キーやイベントの本文をエラーレポートに含めないでください。
その他の確認については トラブルシューティングを参照してください。
リリース用バンドルで Expo の Debug ID を保持する
Expo の Metro の設定を LogBrew 経由で作成します。これで、実行時のバンドルにソースマップと同じ Debug ID が付きます。withLogBrewMetroConfig() で囲みます。このラッパーを Expo で使わないでください。使うと、本番環境のビルドが getLogBrewExpoConfig() を案内するメッセージで止まります。