私はいくつかの機能を持つアプリケーションを構築しています:ContentProvider、SyncAdapter、Jobサービス、および関連する永続ロジック。これらの上に、UIのアクティビティがあります。理論的には、ロジックは独立型であり、どのアプリケーションでも再利用できるので、私はこれらのすべての機能を別々のライブラリモジュールに入れようとしています。ダガー2でライブラリモジュールにアプリケーションコンテキストを注入する
今すぐDagger2が来ます。私のライブラリ依存グラフの最初のノード(メインコンポーネント)はContextを提供する必要があり、ライブラリスコープのライフサイクルがアプリケーションのライフサイクルと同じであるため、このコンテキストをアプリケーションから注入する必要があります。明らかに私のライブラリは私のアプリケーションクラスを直接使うべきではありません。 hereが示唆したように、私のアプリケーションでは、ライブラリの主なコンポーネントを構築し、グローバルな静的クラス/列挙型に格納し
- が、私は、このような静的な参照を使用していることを心配:
これらは私が考える可能性があります反パターンになる可能性があります。
- ライブラリには、ライブラリスコープのコンポーネントを作成するアプリケーションクラス、ライブラリ内のこのクラスにアプリケーションコンテキストをキャストしてコンポーネントを使用し、メインアプリケーションでこのアプリケーションクラスを拡張するApplicationクラスがあります。これはうまくいきますが、複数のライブラリがあれば、もはや実行可能ではありません。
- ファクトリパターンを使用します。ローカルに使用可能なコンテキストがパラメータとして指定されたファクトリを提供するライブラリコンポーネントにプロビジョニングメソッドを配置します。 (説明したようにhere)。これは余分な複雑さを追加するが、実行可能なようだ。
- 最後に、アプリケーションのコンテキストに依存するため、モジュール化の概念が破綻するため、コンポーネントをモジュール化しようとするのをやめてください。
これを行う正しい方法は何ですか。
私は同じことをしたいと思います。あなたは解決策を見つけましたか? –
私はこの質問を忘れてしまった:)私は解決策を見つけた、私の答えは以下を参照してください。 – devrocca