プッシュ通知は出来事を知らせる合図であり、業務データの正本ではない。別の端末で作業票を処理した後に通知を開く可能性がある。payload の状態だけを信じると、無効になった操作を表示してしまう。

三つの入口を同じ形にする

前景で受信、背景でタップ、コールドスタートの初期通知をすべて { eventId, targetType, targetId } に変換する。イベント ID で重複を除き、セッション復元後に対象を再取得する。未読件数はサーバーを基準とし、楽観的に既読にした場合も失敗時には戻す。

通知には遷移用 ID だけを入れ、トークンや完全な個人情報、注文の最終状態は入れない。削除済み、権限なし、処理済みを区別して案内する。

実機で確認する

前景、背景、アプリ終了、通知権限オフ、連続タップ、ログイン利用者の変更を確認する。Expo では開発ビルドでプッシュを検証し、Expo Go の挙動だけで本番を判断しない。

プッシュは通知であり、本文の正本ではない

サポート用の受信箱を考える。サーバーがメッセージを保存して通知を送っても、端末は同期前に通知を受けたり、同じ通知を 2 回受けたり、別端末で既読にした後で遅延通知を受けたりする。通知には安定した messageId、会話 ID、重複排除用のイベント ID を持たせ、詳細とバッジはサーバーのメッセージ状態に従わせる。通知の到着順はメッセージの順序ではなく、到着だけで未読数を恒久的に増やさない。

フォアグラウンドで受けたら、イベント ID を短期の重複排除集合に入れ、その会話を差分同期する。バックグラウンドから通知を押した場合は、セッションを復元し、サーバーからメッセージを取得してから遷移する。撤回済みまたは現アカウントに権限がなければ、キャッシュした私的な本文ではなく安全な利用不可画面を出す。前景コールバック、通知タップ、復帰同期が同じ取得を起こし得るので、データ層でまとめる。

保存(version=42) → event=E9 を送信 → 端末が E9 を 2 回受信
  → 重複排除して 1 回取得 → messageId で統合 → サーバー未読数を採用

バッジと既読通知を回復可能にする

会話を開いたときはローカルで既読表示にしてもよいが、要求失敗時は「未確定」を残して再試行する。端末間同期後はサーバーが確認した readThrough や版で水位を進める。バッジには確認済みの総未読数を用い、オフラインなら未同期の可能性を示す。重複・逆順通知、権限取消、オフライン、コールドスタートからのタップ、アカウント切替を試し、前アカウントの私的な内容が漏れないことを確認する。

参考：Expo プッシュ通知。