在项目中怎么灵活使用Dagger?

1. 使用Dagger的场景太少了,大部分只是使用Dagger注入MVP类,并且有些Retrofit都是自己new,并没有使用Dagger管理,甚至有些使用一次接口就retrofit.create(ApiService.class)一次,这个本可以使用Dagger将它作为单例来调用的
2. 有一些设计的Component和Module完全只是用来注入Activity和一些单例

@ActivityScope @Component(modules = {ActivityModule.class},dependencies = {AppComponent.class}) public interface ActivityComponent { void inject(AActivity activity); void inject(BActivity activity); void inject(CActivity activity); ... } 只要多一个Activity,他就可以一直重载inject方法,于是就可以用一组component,module来为所有Activity注入,但是如果遇到Activity需要临时注入一些其他的组件,并且每个Activity要注入的组件都不一样,就没办法了,缺少灵活性

1. 还是和第2条有关,如果只有一个Module,Dagger就无法根据每个Presenter的需要,提供多个不同的Model,比如这个Presenter使用过这个接口,并且缓存已经在Model中写好,其他Presenter如果也要用到这个接口,就可以直接重用这个Model,MVP最大的好处之一就是可以重用M和P层
2. 有些没有Model层,直接给Presenter注入Retrofit Api(有些是注入一个管理类,如果项目小接口少,这样还不错,但是有没有想过项目一大,接口一多里面就非常混乱),所有网络请求逻辑在Presenter中,如果现在需求变了,需要加入缓存,就需要更改Presenter的逻辑,这样就可能影响一些和这个功能无关的逻辑,如果有Model层,里面持有请求网络和缓存的功能类,这样Presenter就不需要管,数据是从网络还是数据库获取的,Model层只用保证返回给Presenter的数据无误,而Presenter只用专注于逻辑,这样各自只用保证各自的职责,屏蔽细节,易扩展,出错也好定位

如何用? 在项目中用到最多的就是向Presenter提供View和Model的同时,在向每一层提供所需要的单例类,并且使用Dagger不断的重用Presenter和Model,其实Dagger本来就抽象,说再多不如直接看代码是怎么实现的,然后照着模版直接在自己项目中使用,本文的主题不就是在项目中怎么灵活使用Dagger吗?那就直接在项目中找答案不是更快? Launch? Hello 我叫Jessyan,如果您喜欢我的文章,可以在以下平台关注我?

• GitHub: https://github.com/JessYanCoding
• 掘金: https://gold.xitu.io/user/57a9dbd9165abd0061714613
• 简书: http://www.jianshu.com/u/1d0c0bc634db