Android MVP+Retrofit+dagger 2+RxAndroidフレームワーク統合(7)---Daagger 2編
5356 ワード
作者:hwj 3747转载请注明
目次(1)配置編 (2)Lambda式 (3)icepick編 (4)butterknife編 (5)MVP編 (6)Retrofit編 (7)Dagger 2編 (8)RxAndroid/RxJava編 dagger 2とは
DaggerはAndroidとJavaプラットフォームのために提供された完全な静的で、コンパイル時に依存注入を行うフレームワークで、もともとSquare社が維持していたが、現在はGoogleが維持している.一言で言えば、dagger 2は実は依存注入フレームワークである.では、依存注入とは何でしょうか.具体的には、あるロール(Javaインスタンス、呼び出し者)が別のロール(別のJavaインスタンス、呼び出し者)の協力を必要とする場合、従来のプログラム設計では、呼び出し者によって呼び出し者のインスタンスが作成されることが多い.しかしdagger 2では、呼び出し元を作成する作業は呼び出し元ではなく、dagger 2によって完了し、呼び出し元に注入されるため、依存注入とも呼ばれる.
なぜdagger 2が必要なのか
正直に言うと、dagger 2に触れたばかりの頃、私も愚かな顔をしていました.これはこんなに煩わしいのに、どうしてそれを使うのですか.この問題は、注入に依存する必要がある理由です.注入に依存することは目的ではなく、一連のツールと手段であり、最終的な目的は、緩やかな結合、メンテナンス、テスト可能なコードとプログラムの開発を支援することであると本に書いてある.最終的な目的は、デカップリングを実現することであることが考えられる.デカップリングとは?どうやってデカップリングしますか?例を挙げて説明します.MVPアーキテクチャについて説明します.Presenterレイヤ構築関数には、サービス側のAbsServiceインスタンスにアクセスし、ネットワーク要求スレッドを切り替えるSchedulerProviderが必要です.次のようにします.
このPresenterをインスタンス化するには
TestPresenterに必要なパラメータを一つ一つインスタンス化し、パラメータとして渡す必要があります.考えてみてください.AbsServiceとSchedulerProviderには多くのパラメータが必要です.あるいはTestPresenterには3つ以上のパラメータが必要です.TestPresenterの操作が多すぎるのではないでしょうか.これは大げさです.TestPresenterのインスタンスが必要です.TestPresenterのDependencyが何なのかを知らなければなりません.TestPresenterのDependencyのDependencyって何ですか...まずこのようにするのは操作が煩雑で、次に、このようにして、コードの結合の程度が非常に高くなって、私たちがその中の一環を変える時、大量のコードの変更をしなければなりません.しかし、dagger 2を使用すれば、これらの問題は解決することができます.dagger 2は依存工場のようなものを用いて、必要な依存を統一的に管理し、依存する必要があるすべてのクラスがここに来て対応する依存を探すことができ、dagger 2はこのクラスが使用する依存を自動的に検索し、システムはこの依存関係を自動的に識別する.
Dagger 2の基本的な使い方
Dagger 2は主に2つの部分から構成されています.まず、依存する工場Moduleが必要です.次に、これらのModuleを管理する管理者Componentが必要です.Moduleの実装(前の例に続く):
上のModuleクラスでは、このクラスを@Module注釈で表記し、dagger 2というクラスが依存を提供するModuleであることを示し、以下の@Provides注釈で表記する方法の多くはdagger 2という方法で依存を提供することを示す.単一例の依存性を提供する必要がある場合は、@Singleton注記を追加する必要があります.この時、疑問に思う人もいるかもしれませんが、多層依存daggerはどうやって探したのでしょうか.dagger 2依存を探すルールは次のとおりです.手順1:まず@Moduleタグのクラスに依存を提供する方法があるかどうかを検索します.手順2:依存メソッドがある場合は、そのメソッドにパラメータがあるかどうかを確認します.a:パラメータが存在する場合は、ステップ1から順に各パラメータを初期化する.b:存在しない場合は、クラスインスタンスを直接初期化し、依存注入を完了する.手順3:依存メソッドが存在しない場合は、@Injectタグ付けのコンストラクション関数を検索し、コンストラクション関数にパラメータが存在するかどうかを確認します.a:パラメータが存在する場合は、ステップ1から各パラメータbを順次初期化する:存在しない場合は、クラスインスタンスを直接初期化し、依存注入を完了する.このような操作により、dagger 2は必要な依存を直接自動的に探すことができる.
Componentの実装:
または
Componentは@Componentで修飾してdagger 2のComponentと表記する必要があります.普通のinterfaceではなくmodules=AppModuleで表記します.classはdagger 2がどのModuleから依存を探すかを教えに来て、複数のModuleがあれば、最初の方法と同じように配列の形式に書くことができることに注意します.Componentでのメソッドは、依存を使用する必要がある場合に使用されます.たとえば、最初は直感的にTestPresenterというインスタンスが必要です.このメソッドを直接定義すると、dagger 2はDagger+Component名前(DaggerAppComponentなど)というメソッドを自動的に生成します.このメソッドは、AppComponentが管理するAppModuleから依存を探し、Presenterのインスタンスを返します.次に、インスタンスを呼び出す必要がある場合は、次のようにすればインスタンス化が完了します.
2つ目の方法では、次のように呼び出す必要があります.
DaggerAppComponentがこの方法を実装する方法は,TestActivity Fragment 2内の@Injectによって修飾されたすべての変数を除去し,AppModule対応するProviderメソッドを呼び出して対応するタイプに依存することである.この2つの方法については、一般的に2つ目を選んで、書くのが簡単です.以上、私が知っているdaggerの基本的な使い方はこれだけです.
目次
DaggerはAndroidとJavaプラットフォームのために提供された完全な静的で、コンパイル時に依存注入を行うフレームワークで、もともとSquare社が維持していたが、現在はGoogleが維持している.一言で言えば、dagger 2は実は依存注入フレームワークである.では、依存注入とは何でしょうか.具体的には、あるロール(Javaインスタンス、呼び出し者)が別のロール(別のJavaインスタンス、呼び出し者)の協力を必要とする場合、従来のプログラム設計では、呼び出し者によって呼び出し者のインスタンスが作成されることが多い.しかしdagger 2では、呼び出し元を作成する作業は呼び出し元ではなく、dagger 2によって完了し、呼び出し元に注入されるため、依存注入とも呼ばれる.
なぜdagger 2が必要なのか
正直に言うと、dagger 2に触れたばかりの頃、私も愚かな顔をしていました.これはこんなに煩わしいのに、どうしてそれを使うのですか.この問題は、注入に依存する必要がある理由です.注入に依存することは目的ではなく、一連のツールと手段であり、最終的な目的は、緩やかな結合、メンテナンス、テスト可能なコードとプログラムの開発を支援することであると本に書いてある.最終的な目的は、デカップリングを実現することであることが考えられる.デカップリングとは?どうやってデカップリングしますか?例を挙げて説明します.MVPアーキテクチャについて説明します.Presenterレイヤ構築関数には、サービス側のAbsServiceインスタンスにアクセスし、ネットワーク要求スレッドを切り替えるSchedulerProviderが必要です.次のようにします.
public class TestPresenter extends BasePresenter {
AbsService mAbsService;
SchedulerProvider mSchedulerProvider;
public TestPresenter(AbsService absService,SchedulerProvider schedulerProvider) {
this.mAbsService=absService;
this.mSchedulerProvider=schedulerProvider;
}
}
このPresenterをインスタンス化するには
AbsService mAbsService=AbsService.getInstance();
SchedulerProvider schedulerProvider=SchedulerProvider.DEFAULT;
TestPresenter testPresenter=new TestPresenter(mAbsService,schedulerProvider);
TestPresenterに必要なパラメータを一つ一つインスタンス化し、パラメータとして渡す必要があります.考えてみてください.AbsServiceとSchedulerProviderには多くのパラメータが必要です.あるいはTestPresenterには3つ以上のパラメータが必要です.TestPresenterの操作が多すぎるのではないでしょうか.これは大げさです.TestPresenterのインスタンスが必要です.TestPresenterのDependencyが何なのかを知らなければなりません.TestPresenterのDependencyのDependencyって何ですか...まずこのようにするのは操作が煩雑で、次に、このようにして、コードの結合の程度が非常に高くなって、私たちがその中の一環を変える時、大量のコードの変更をしなければなりません.しかし、dagger 2を使用すれば、これらの問題は解決することができます.dagger 2は依存工場のようなものを用いて、必要な依存を統一的に管理し、依存する必要があるすべてのクラスがここに来て対応する依存を探すことができ、dagger 2はこのクラスが使用する依存を自動的に検索し、システムはこの依存関係を自動的に識別する.
Dagger 2の基本的な使い方
Dagger 2は主に2つの部分から構成されています.まず、依存する工場Moduleが必要です.次に、これらのModuleを管理する管理者Componentが必要です.Moduleの実装(前の例に続く):
@Module
public class AppModule {
@Provides
public SchedulerProvider provideSchedulerProvider() {
return SchedulerProvider.DEFAULT;
}
@Provides
public AbsService provideApi() {
return AbsService.getInstance();
}
@Provides
public AbsService.AbsApi provideAbsApi() {
return AbsService.getService();
}
@Provides
public TestPresenter providePresenter(AbsService absService,SchedulerProvider schedulerProvider) {
return new TestPresenter(absService,schedulerProvider);
}
}
上のModuleクラスでは、このクラスを@Module注釈で表記し、dagger 2というクラスが依存を提供するModuleであることを示し、以下の@Provides注釈で表記する方法の多くはdagger 2という方法で依存を提供することを示す.単一例の依存性を提供する必要がある場合は、@Singleton注記を追加する必要があります.この時、疑問に思う人もいるかもしれませんが、多層依存daggerはどうやって探したのでしょうか.dagger 2依存を探すルールは次のとおりです.手順1:まず@Moduleタグのクラスに依存を提供する方法があるかどうかを検索します.手順2:依存メソッドがある場合は、そのメソッドにパラメータがあるかどうかを確認します.a:パラメータが存在する場合は、ステップ1から順に各パラメータを初期化する.b:存在しない場合は、クラスインスタンスを直接初期化し、依存注入を完了する.手順3:依存メソッドが存在しない場合は、@Injectタグ付けのコンストラクション関数を検索し、コンストラクション関数にパラメータが存在するかどうかを確認します.a:パラメータが存在する場合は、ステップ1から各パラメータbを順次初期化する:存在しない場合は、クラスインスタンスを直接初期化し、依存注入を完了する.このような操作により、dagger 2は必要な依存を直接自動的に探すことができる.
Componentの実装:
@Component(modules = {AppModule.class})
public interface AppComponent {
TestPresenter testPresenter();
}
または
@Component(
modules = AppModule.class
)
public interface AppComponent {
TestActivityFragment2 inject(TestActivityFragment2 activity);
}
Componentは@Componentで修飾してdagger 2のComponentと表記する必要があります.普通のinterfaceではなくmodules=AppModuleで表記します.classはdagger 2がどのModuleから依存を探すかを教えに来て、複数のModuleがあれば、最初の方法と同じように配列の形式に書くことができることに注意します.Componentでのメソッドは、依存を使用する必要がある場合に使用されます.たとえば、最初は直感的にTestPresenterというインスタンスが必要です.このメソッドを直接定義すると、dagger 2はDagger+Component名前(DaggerAppComponentなど)というメソッドを自動的に生成します.このメソッドは、AppComponentが管理するAppModuleから依存を探し、Presenterのインスタンスを返します.次に、インスタンスを呼び出す必要がある場合は、次のようにすればインスタンス化が完了します.
public class TestActivityFragment2 extends Fragment {
private TestPresenter mTestPresenter;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
AppComponent appComponent = DaggerAppComponent.builder().appModule(new AppModule(this)).build();
mTestPresenter= appComponent.testPresenter();
}
}
2つ目の方法では、次のように呼び出す必要があります.
public class TestActivityFragment2 extends Fragment {
@Inject
TestPresenter mTestPresenter;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
AppComponent appComponent = DaggerAppComponent.builder().appModule(new AppModule(this)).build();
appComponent.inject(this);
}
}
DaggerAppComponentがこの方法を実装する方法は,TestActivity Fragment 2内の@Injectによって修飾されたすべての変数を除去し,AppModule対応するProviderメソッドを呼び出して対応するタイプに依存することである.この2つの方法については、一般的に2つ目を選んで、書くのが簡単です.以上、私が知っているdaggerの基本的な使い方はこれだけです.