本节引言
前面我们分析了很多Dagger的注解，现在应该有个较全面的认识了。但dagger之所以比别的第三方模块难就是因为它比较抽象，包含的东西还挺多，接下来我们要讨论一些深一点的话题了
进一步讨论Component
既然是组件那就代表这东西可能不止一个，而且之间还可能存在联系。
dagger2的组件之间可能是这3中关系
- 完全独立
- 组件之间有依赖关系，但相对独立
- 成对出现，可说是父子关系
前边我们已经比较依赖我们的实例，现在仍然利用它来进行说明吧
完全独立
完全独立这个关系虽然好理解，但也说一说吧
我们还是来丰富我们原来的demo(只是为了偷懒实际上和之前的逻辑没关系)，但为了更清楚的理解Component的各种关系，我们对新增的一些类不提供@Inject构造函数。
假设我们要在主界面展示一台电脑和一台打印机的信息（界面弄个按钮，输出点信息模拟就是了)
先来创造两个类(非常简单的类,就一个名字),两个Module,两个Component
class Computer(private val name:String){
override fun toString() = "Computer:$name"
}
class Printer(private val name:String){
override fun toString() = "Printer:$name"
}
@Module
class ComputerModule{
@Provides
fun getComputer()=Computer("戴尔")
}
@Module
class PrinterModule{
@Provides
fun getPrinter()=Printer("惠普")
}
@Component(modules = [ComputerModule::class])
interface ComputerComponent{
fun makeComputer():Computer
}
@Component(modules = [PrinterModule::class])
interface PrinterComponent{
fun makePrinter():Printer
}
然后修改UI代码新增代码如下
...
lateinit var myComputer:Computer
lateinit var myPrinter:Printer
...
myComputer = DaggerComputerComponent.create().makeComputer()
myPrinter = DaggerPrinterComponent.builder().build().makePrinter()
buttonShowInfo.setOnClickListener {
textViewInfo.text = "$myComputer, $myPrinter"
}
点击按钮，我们会看到一切都是按照预期
dell.png
好现在就是两个独立的Component，如果你看了前几节，到目前为止的代码，你都应该能轻松理解。
组件之间有依赖关系，但相对独立
现在我们发现打印机需要一个print功能，但我们发现这个print功能没有电脑不行，打印机无法自己打印，先来修改我们的Printer相关类：
class Printer(private val name:String, private val cpu:Computer){
fun print() = "$cpu is working"
override fun toString() = "Printer:$name"
}
@Module
class PrinterModule{
@Provides
fun getPrinter(cpu:Computer)=Printer("惠普", cpu)
}
现在挠头的事情来了，这个打印机需要一个computer参数，这我上哪给你弄去？Dagger又出新主意了，就是让一个Component可以依赖一个或多个其它Component。 先来改写代码
@Component(modules = [PrinterModule::class], dependencies = [ComputerComponent::class])
interface PrinterComponent{
fun makePrinter():Printer
}
看到了吧PrinterComponent指定了依赖ComputerComponent, 还需要改写UI代码来明确这种依赖,自己理解下吧，我就不啰嗦了（可以看Dagger生成的源码）
val cpuCom = DaggerComputerComponent.create()
myComputer = cpuCom.makeComputer()
myPrinter = DaggerPrinterComponent.builder().computerComponent(cpuCom).build().makePrinter()
这种依赖，两个component的也可以说是相互独立的，printer component也可以单独创建，不过没法构建我们希望的printer就是了
成对出现，可说是父子关系
现在我们还有另外一个类，叫做虚拟打印机，这个类和电脑的关系更密切，脱离电脑根本就不可能存在。鉴于这种紧密关系，我们称电脑和虚拟打印机是父子关系，鉴于我们现在已经很熟悉了，把相关的类一股脑贴出来吧:
class VirtualPrinter(private val name:String, private val cpu:Computer){
override fun toString() = "VirtualPrinter:$name"
}
@Module
class VirtualPrinterModule{
@Provides
fun getVirtualPrinter(cpu:Computer)=VirtualPrinter("微软虚拟打印机", cpu)
}
@Component(modules = [ComputerModule::class])
interface ComputerComponent{
fun makeComputer():Computer
fun makeVirtualComponent():SubComponentVirtualPrinter
}
@Subcomponent(modules = [VirtualPrinterModule::class])
interface SubComponentVirtualPrinter{
fun makeVirtualPrinter():VirtualPrinter
}
UI代码
...
lateinit var myVirtualPrinter:VirtualPrinter
...
val cpuCom = DaggerComputerComponent.create()
myComputer = cpuCom.makeComputer()
myPrinter = DaggerPrinterComponent.builder().computerComponent(cpuCom).build().makePrinter()
myVirtualPrinter = cpuCom.makeVirtualComponent().makeVirtualPrinter()
buttonShowInfo.setOnClickListener {
textViewInfo.text = "$myComputer, $myPrinter, $myVirtualPrinter, ${myPrinter.print()}"
}
...
我们看到了一个新的关键字@Subcomponent这就表明这个component是一个子组件，在本例中这个子组件是通过其父组件ComputerComponent的makeVirtualComponent方法来提供的。 在这种关系中子组件是不能单独存在的，必须先有父组件才能有子组件。 如果想深挖请看下源码吧，其实也没啥。
本着趁热打铁的精神，我们来继续引入一个概念(实际上我这个使用教程就是官方文档介绍关键字的顺序。。。)
惰性的注入
你可能会说：你这个demo不行，如果用户不点击“User”按钮，不是白白创建User实例了吗，浪费资源啊。我反驳说：大哥，我这是demo不是产品。不，你说的对，我改还不行吗！！！那我先抄一段官方文档的文字行不？
有时需要延迟实例化对象。对于任何绑定T，都可以创建一个Lazy<T>，它将实例化延迟到第一次调用Lazy<T>的get()方法时。如果T是一个单例，那么Lazy<T>将是ObjectGraph中所有注入的相同实例。否则，每个注入站点将获得自己的惰性<T>实例。无论如何，对Lazy<T>的任何给定实例的后续调用都将返回相同的T的底层实例。
class GrindingCoffeeMaker {
@Inject Lazy<Grinder> lazyGrinder;
public void brew() {
while (needsGrinding()) {
//Grinder在第一次调用.get()时创建了一次并缓存了它。
lazyGrinder.get().grind();
}
}
}
那我们现在就把我们的User对象改成Lazy的
lateinit var user:Lazy<User>
去掉原来初始化User的代码，在按钮点击中:
buttonUser.setOnClickListener {
user.get().apply {
name = "Hero"
car.name = "大众"
gotoCompany()
textViewInfo.text = toString()
}
}
运行一切okay，没啥问题。这个Lazy还不错，毕竟用的时候在创建类是个不错的事情(computer实例，可以用kotlin自己的lazy体制，就不介绍了)。
提供者注入
有时您需要返回多个实例，而不是只注入一个值。当您有几个选项(工厂、构建器等)时，一个选项是注入Provider<T>而不仅仅是T。Provider<T>每次调用.get()时都会为T调用绑定逻辑。如果该绑定逻辑是@Inject构造函数，那么将创建一个新的实例，但是@Provides方法没有这样的保证。
class BigCoffeeMaker {
@Inject Provider<Filter> filterProvider;
public void brew(int numberOfPots) {
...
for (int p = 0; p < numberOfPots; p++) {
maker.addFilter(filterProvider.get()); //每次换一个新filter。
maker.addCoffee(...);
maker.percolate();
...
}
}
}
这玩意我实在想不出啥时候有用,就不分析了, 在来分析一个不太常用的吧
可选的绑定
这个好像有点用吧，我们还是用我们的实例来进行点发挥和说明吧，比如我们的Car类，可以有引擎，也可以没有引擎，当然没引擎的话自然无法执行gotoCompany方法咯，那怎么办呢？这就需要使用@BindsOptionalOf注解了，来看一下官方对此注解的说明吧
如果你想要绑定可以工作，即使某些依赖没有绑定到组件中，你可以添加一个@BindsOptionalOf方法到一个模块:
@BindsOptionalOf abstract CoffeeCozy optionalCozy();
这意味着@Inject构造函数和成员以及@Provide方法可以依赖于一个Optional<CoffeeCozy>对象。如果组件中有对CoffeeCozy的绑定，则会出现这个"Optional", 如果没有绑定的CoffeeCozy，这个"Optional"将缺席。
请认真理解吧，让我组织更自然的语言来解释它，我也不会，改造我们的实例，贴代码看看
class Car @Inject constructor(val engine:Optional<Engine>){//改造car类添加Optional,说明此字段可能为空
lateinit var name:String
}
@Module
interface EngineModule{//改造Module来说明这个Engine是个可选注入
@BindsOptionalOf
fun optionalEngine():Engine
}
class User @Inject constructor(val age: Int, val car: Car, val pad: SafeNotePad)
{
lateinit var name:String
@RequiresApi(Build.VERSION_CODES.N)
fun gotoCompany()//改造此方法，以适应car可能没引擎的情况,没引擎则什么也不做
{
if(car.engine.isPresent)
{
car.engine.get().on()
Log.i("zrm", "$name goto company")
car.engine.get().off()
}
}
override fun toString(): String {
return "User Name:$name, Age:$age, Car:${car.name}, $pad"
}
}
那么现在运行程序，会发现，gotoCompany什么也没做，因为引擎为空了，如果不做@BindsOptionalOf的注释，engine如果不提供Provider的话，是编译不过的，自己可以试试。
既然是可选，那就代表也可以有引擎，那我们来写个提供引擎的Module并加入到Component中
@Module
class EngineModuleChina{
@Provides
fun getEngine(): Engine {
return ChinaEngine()
}
}
@Component(modules = [UserModule::class, EngineModule::class, EngineModuleChina::class])
interface MainComponent{
fun inject(activity: MainActivity)
}
此时我们运行程序，发现gotoCompany又可以正常工作了。一切到达了预期
思考：这玩意(@BindsOptionalOf)啥时候有用呢，可能是你设计一个类，有很多字段都是需要注入的，但有的字段由于工作进度等等还没设计好提供方法，就可以用这玩意。 等你有了Provider就不用改很多代码了，就添加个Provider就行了。还有别的用途吗？？不想了。。。
还想继续，但到目前为止感觉已经基本够用了，等有时间在来个终章，把剩下的一些不太常用的东西继续说说，无论如何本节到此为止吧。
网友评论