Android In-App-Billing V3 で見つけることができるすべてのチュートリアルでは、請求関連のすべてを処理する 1 つのアクティビティがあることを前提としています。私の場合、請求へのアクセスが必要なアクティビティが複数あります。そのようなことを最もエレガントに処理するにはどうすればよいでしょうか?
私が遭遇した問題の 1 つの例: Google 課金ヘルパー クラスを使用する場合、常に現在のアクティビティをパラメーターとして渡します。後でコールバック (onActivityResult など) がそのアクティビティで呼び出されます。しかし、アクティブなアクティビティが常に変化する場合はどうなるでしょうか? 常に請求をシャットダウンして再初期化する必要がありますか?
しかし、アクティブなアクティビティが常に変化する場合はどうなるでしょうか? 常に請求をシャットダウンして再初期化する必要がありますか?
悪いことは何もありません。サービスへの接続は非常に高速です。最も重要なのは、アクティビティが再開されたときに onActivityResult() コールバックを処理できるようにすることです。
そのようなことを最もエレガントに処理するにはどうすればよいでしょうか?
あなたが書いたアプリケーションの種類がわかりません。ゲームの場合は、1 つのアクティビティで構成されている可能性が高く、いずれにせよ問題はありません。それが複数のアクティビティを持つ他の種類のアプリケーションである場合、私の意見では、ユーザーがすべてのアプリ内製品 (購入および購入) を見ることができる単一のアクティビティを用意することをお勧めします。これは「内部ストア」アクティビティのようなものです。このアクティビティは請求サービスに接続できます。他のアクティビティは、ユーザーがアプリ内製品の詳細を読んで購入を決定できる「内部ストア」に転送する必要があります。とても便利だと思います。
別のアプローチは、すべてのアクティビティで再利用できる Fragment に課金ロジックを実装することです。onActivityResult()結果をオーバーライドしてそのフラグメントに転送するだけです。これが私のアプリに実装した方法です。
お役に立てれば。
例のボックスの外で少し考えてください。それはあなたの問題だけに関係するのではなく、一般的なものです。
1 つのパブリッシャーと多くのリスナーが必要なため (ケース 2)、通知システムを使用します。1つの最も醜い方法は次のとおりです（しかし、書くのが最も速い）：
助けられた、または好きだった場合、5番目の賛成票:)