プッシュ通知

アプリが閉じている間も担当者の返信やキャンペーンを、適切な会話へまっすぐ入るディープリンクとともに配信します。プッシュのサブシステムはアプリが所有し、SDK はトークンの登録と会話のオープンを担います。

Respondo が送るもの#

メッセージのプッシュ — 訪問者が参加している会話での担当者または AI の返信。
キャンペーンのプッシュ — アウトバウンドのプッシュキャンペーン。開封ビーコンも報告します。

メッセージのプッシュは常に次の形式のディープリンクを含みます： respondo://conversation/<id>。キャンペーンのプッシュはキャンペーンで設定されたディープリンクを含みます — これは任意で、設定されていない場合、プッシュにはディープリンクが含まれません。

Apple（APNs）#

iOS のプッシュは APNs で直接動作します——Firebase への依存はありません。Apple Developer アカウントから次を取得します：

APNs 認証キー（.p8 トークンキー）。
そのキーの Key ID。
あなたの Team ID。
アプリの bundle id。

Google（FCM）#

Android のプッシュは Firebase Cloud Messaging を経由します。Firebase プロジェクトから次を取得します：

Cloud Messaging ロールを持つ サービスアカウント JSON。
Firebase プロジェクト ID（Firebase コンソール → Project settings）— ダッシュボードのプッシュ設定フォームで、サービスアカウント JSON と並ぶ専用フィールドに入力します。
Android アプリの パッケージ名。そしてアプリを同じ Firebase プロジェクトに接続します（google-services.json）。

Respondo での設定#

ダッシュボードで、ウィジェットチャネルに APNs キーと、プロジェクト ID を添えた FCM サービスアカウントを追加します。両プラットフォームへ送信するために Respondo が必要とするのはこれだけです。

API 経由での認証情報の設定と全フィールドのリファレンスは、SDK アクセスとともに提供されるプッシュ設定ガイドで扱っています。

ペイロードの形式#

ペイロードは常にルートの respondo キーの下に置かれます——その存在によって SDK は自分のプッシュを他のものと見分けます（iOS では userInfo 内、Android では data["respondo"] 内の JSON 文字列として）。

respondo ペイロードjson

{
  "respondo": {
    "type": "message",
    "conversation_id": "a1c4e7b2-5d38-4f6a-9e10-3b7c2d5f8a90",
    "message_id": "e9a3c1f6-4b8d-4e0a-b5f3-1d7b2a4e9c63",
    "deep_link": "respondo://conversation/a1c4e7b2-5d38-4f6a-9e10-3b7c2d5f8a90"
  }
}

すべての値はフラットな文字列です。通知のタイトルと本文はプラットフォームのトランスポートによって配信されます — APNs では aps.alert、FCM では message.notification — respondo オブジェクトの中には含まれません。

キャンペーンのプッシュには、開封ビーコンの報告に使う delivery_id も含まれ、キャンペーンのプッシュデータからの追加のフラットな文字列キーを含むことがあります。

タップとフォアグラウンドの処理#

通知がタップされたら、生のペイロードを SDK に渡します。SDK はペイロードを解析して適切な会話を開き、Respondo のプッシュでない場合は false を返します（その場合は自分で処理してください）。

タップの処理（プラットフォームごと）text

Android:  RespondoPushPayload.from(data)?.let { Respondo.handlePush(it) }
iOS:      Respondo.handlePush(userInfo: userInfo)
Flutter:  Respondo.handlePushData(message.data)

重複は message_id でまとめられ、同じ会話がフォアグラウンドで開いている間はシステム通知が抑制されます——SDK が両方を自動的に処理します。

デバイストークンの登録#

アプリは自身のプッシュサブシステムからデバイストークンを取得し、それを setPushToken に渡します。ログアウト時には clearPushToken を呼び出します。

どのトークンを渡すか。バックエンドは各配信をプラットフォームごとにルーティングします——iOS は APNs へ直接、Android は FCM へ——そのため、プッシュライブラリがたまたま返すものではなく、プラットフォームのネイティブなトランスポートのトークンを登録しなければなりません：

Android — FirebaseMessaging.getToken() からの FCM 登録トークン。
iOS（ネイティブ） — didRegisterForRemoteNotificationsWithDeviceToken からの APNs デバイストークン（hex）。
Flutter 経由の iOS（firebase_messaging）—— getAPNSToken() を使い、 getToken() は使わないこと。iOS で FCM トークンを渡すとそれが APNs に送られますが、そこでは有効なデバイストークンではないため、プッシュは決して届きません。 getAPNSToken() は起動直後のわずかな間 null になることがあります——その場合は少し待ってから再試行してください。

Android — FirebaseMessagingServicekotlin

override fun onNewToken(token: String) {
    Respondo.setPushToken(token)
}

iOS — AppDelegateswift

func application(
    _ application: UIApplication,
    didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data
) {
    let token = deviceToken.map { String(format: "%02x", $0) }.joined()
    Respondo.setPushToken(token)
}

Flutter — firebase_messagingdart

// iOS には APNs トークンが必要、Android には FCM トークンが必要。
final token = Platform.isIOS
    ? await FirebaseMessaging.instance.getAPNSToken()
    : await FirebaseMessaging.instance.getToken();
if (token != null) Respondo.setPushToken(token);

// FCM は登録トークンをローテーションする。Android を同期し続ける。
if (!Platform.isIOS) {
  FirebaseMessaging.instance.onTokenRefresh.listen(Respondo.setPushToken);
}