Dependency Injection in Android: Use of the Dagger function library (i)

--Welcome Reprint, please specify the source http://blog.csdn.net/asce1885, without my consent do not use for commercial purposes, thank you--

Original link: http://antonioleiva.com/dependency-injection-android-dagger-part-1/

This article Gitbooks link: http://asce1885.gitbooks.io/android-rd-senior-advanced/content/androidzhong_de_yi_lai_zhu_ru_ff1a _dagger_han_shu_ku_de_shi_yong_ff08_yi_ff09.html

In this new series, I'll explain what dependency injection is, what its main purpose is, and how dagger libraries are implemented in Android engineering, and Dagger is currently the most popular dependency injection function library designed for Android.

This article is a follow-up to the previous article, "MVP implementation in Android," because I believe some of the readers will be happy to see that these two features are implemented in the same project, and I think they work well together.

This article will only introduce basic theoretical knowledge to lay the groundwork. It is important to understand the concept of dependency injection and the reasons for its existence, and we will consider the benefits less than the effort.

What is Dependency injection

If we want to inject dependency, we must first understand what dependence is. To put it simply, dependency is the coupling between two modules in our code (in object-oriented languages, two classes), usually one of which uses another provided function.

Why is Reliance Dangerous?

Dependencies from the upper to the bottom are dangerous because we are coupling two modules to some extent, so that when one of the modules needs to be modified, we have to modify the code of the modules that are coupled to them. This is bad for creating a testable app, because unit testing requires testing a module to ensure that it is isolated from other modules in the app. To do this, we need to use mocks instead of dependencies and imagine this code:

public class Module1{   private Module2 module2;   public Module1(){      module2 = new Module2();   }   public void doSomething(){      ...      module2.doSomethingElse();      ...   } }

How do you test the dosomething function without testing the DOSOMETHINGELSE function? If the test fails, which function is causing it? We don't have any. If the Dosomethingelse function stores data in a database or initiates API requests to the server, things will get worse.

Whenever we hit the new keyword, we should be aware that this may be a strong dependency to avoid. Writing fewer modules is certainly not a solution, and don't forget the principle of single responsibility.

How to solve it? Dependency reversal

If additional modules cannot be initialized within a module, then the modules need to be initialized in other forms. Can you imagine how it could be achieved? That's right, by constructing the function. This is basically the implication of a dependency reversal principle. You should not rely on specific module objects, you should rely on abstractions.

The preceding code should be modified to:

public class Module1{   private Module2 module2;   public Module1(Module2 module2){      this.module2 = module2   }   public void doSomething(){      ...      module2.doSomethingElse();      ...   } }

So what is dependency injection?

You already know it! It passes the dependency (injection) through the constructor, pulling out the task of creating the module from within another module. The object is created elsewhere and passed to another object as a constructor parameter.

But new problems have arisen. If we cannot create other modules within the module, then there must be a place to initialize the modules. Also, if the constructor of the module that we need to create contains a large number of dependent parameters, the code will become ugly and difficult to read, and there will be a large number of objects passed in the app. Dependency Injection was born to solve this kind of problem.

What is a dependency injector?

We can think of it as another module in the app that is dedicated to providing examples of other modules and injecting them with dependencies. This is its basic obligation. The creation of the module focuses on a unified portal in the app, and we have full control over it.

Finally, what is dagger?

Dagger is a dependency injector designed for low-end devices. Most dependency injectors create and inject dependencies through reflection. The reflection mechanism is great, but it takes a lot of time on low-end devices, especially on older Android versions. However, Dagger uses the precompiled compiler to create all the classes required for the job. This way, there is no need to use reflection. Dagger is slightly weaker than other dependency injectors, but it is the most efficient.

Dagger just for testing?

Of course not! It makes it easy to reuse your modules in other apps, or change them in the same app. Imagine an example where your app needs to read data from a local file in debug mode, and in release mode it needs to be fetched from the server-side API request. It is entirely possible to achieve this by injecting different modules into different modes.

Conclusion

I know this article is a bit difficult, but I think it is necessary to make the basic concepts clear before proceeding to the next article. We already know what dependencies are, what improvements are made through dependency inversion, and how we implement it through dependency injectors.

In the next article we will start the real practice, stay tuned!

--Welcome Reprint, please specify the source http://blog.csdn.net/asce1885, without my consent do not use for commercial purposes, thank you--

Dependency Injection in Android: Use of the Dagger function library (i)