アクティビティをAPIのサプライヤとして使用する場合のリスク

Question

私はライブラリモジュールにして、自分のUIが異なるいくつかの他のアプリケーションの共通ロジックとして独自のロジックを使用したいAndroid向けアプリケーションを作成しています。ライブラリモジュールには、アプリケーション自体で定義されているリスナーにコマンドを送受信できるAndroidサービスがあります（私の場合はメインアクティビティで）。

受信側では、リスナーはアプリケーションの主なアクティビティであり、アプリケーションからのメッセージの種類に応じてコールバックを呼び出します。

サービスの部分への送信コマンドの問題が増えています。問題のAPIは、アプリケーションがサービスにメッセージを送信する方法です。メッセージを送信してサービスに渡すだけの引数を取得するだけです。

私がそれをやったと思ったのは、送受信イベントの両方を可能にするAPIとしてのライブラリの主な活動を作ることでした。このライブラリを使用するUIの開発者は、単にGUI用の別のモジュールを作成するだけで、主なアクティビティでライブラリの主なアクティビティを拡張し、APIを使用してリスナの動作を拡張する必要があります。

私が知りたいことは、技術的な問題であり、設計自体が可能な限り良いとは考えていません。このデザインに問題はありますか？たとえば、Androidのアクティビティの廃棄に関する問題がありますか？その他の問題？

Answer 1

アクティビティに基づいてAPIを構築する主なリスクは、基本的にAPIをアクティビティのライフサイクルに縛っていることです。メインスレッドとUIスレッドの両方でメッセージング用のAPIを使用できると仮定します。私は、APIを設計するためにインターフェイスを使用する方が好きです。 Daggerはどこにでも注入できるシングルトンを作成するのに非常に役立ちます。