Firebase で Android の定期購入 (Google Billing Library) その2

久しぶりに定期購入を実装したら色々ハマったので同じように困っちゃっている方の参考になれば幸いです。 その2では、自分なりに理解した登場人物たちの位置関係を図にまとめます。 他の記事も合わせてどうぞ。

登場人物の位置関係

公式ドキュメントの「準備する」の手順を実施すると、だいたい次の図のような登場人物が準備できます。 ただし、この図は私の個人的な理由で複数のアプリやGCPプロジェクトがある場合の記述になっていますので、その点はご了承ください。

Google Play Console Developer プロジェクトの役割

このプロジェクトは、「Google Play Developer API を構成する」で「Google Play デベロッパー アカウント専用の新しい Google Cloud プロジェクトを作成することをおすすめ」されて作ったものになります。 アプリ毎のプロジェクトや開発環境毎のプロジェクトがある場合、どれかを代表として使い回すより推奨されている通り専用のプロジェクトを作った方が良いと思います。 このプロジェクトにサービスアカウントを作成し、各プロジェクトから利用するようにします。 また Google Play Console でも「APIアクセス」の設定にこのサービスアカウントを指定します。 これで「purchases.subscriptions.get」の認証を通すことができるようになります。

Pub/Sub トークン

アプリ毎のプロジェクトにトークンを作成しますが、名前は全部同じにしておく(「billing-notification」など)と、共通処理で名前を切り替えずに決め打ちにでき便利だと思います。 同じ名前にしても、Google Play Console 側からはプロジェクト名込みのトピック名で指定するので、ちゃんと区別できます。 またサブスクライブする方も、アプリのパッケージ名がパラメータに含まれるので、どのアプリの通知か区別することができます。 トークンを作成したら、忘れずに「google-play-developer-notifications@system.gserviceaccount.com」をメンバーに追加して、「Pub/Sub パブリッシャー」ロールを与えておきましょう。(「トピックに関する公開権限の付与」) なお、「Pub/Sub サブスクリプションの作成」でサブスクライバーを登録する手順がありますが、Firebase の Functions で Pub/Sub のイベントハンドラを登録できるので、そちらを利用する場合は動作確認できたら削除で良いです。

その2の最後に

わかっている方には当たり前のことかも知れないですが、全体像が把握できないとなかなかミニマムな設定にできませんでした。 でも分かってしまうと、うまくデザインされていると思いました。さすがグーグル先生ですよね。 「その3」では、「その1」と「その2」を踏まえて作成したコードを説明します。

Firebase で Android の定期購入 (Google Billing Library) その2” に対して2件のコメントがあります。

コメントを残す

メールアドレスが公開されることはありません。