Dependency Injection on Android Platform (I)

When we first started learning software engineering, we often encountered things like this:

Software should comply with SOLID principles.

But what does this actually mean? Let’s look at the important meanings of each letter in SOLID in the context of architecture, for example:

• S - Single Responsibility Principle
• O - Open/Closed Principle
• L - Liskov Substitution Principle
• I - Interface Segregation Principle
• D - Dependency Inversion Principle This is also the core concept of dependency injection.

In simple terms, we need to provide a class that has all the objects it needs in order to implement its functionality.

[[180033]]

Overview

Dependency injection sounds like a term for something very complicated, but it is actually quite simple, as you can see from the following example:

 class NoDependencyInjection {
 private Dependency d;
 public NoDependencyInjection() {
 d = new Dependency();
 }
 }
 class DependencyInjection {
 private Dependency d;
 public DependencyInjection(Dependency d) {
 this.d = d;
 }
 }

As we can see, in the first case we create the dependency object in the constructor, but in the second case it is passed as a parameter to the constructor, which is what we call dependency injection. This is done so that the class we write does not depend on the implementation of a specific dependency, but can use it directly.

If the target of parameter passing is a constructor, we call it constructor dependency injection; or a method, we call it method dependency injection:

 class Example {
  private ConstructorDependency cd;
  private MethodDependency md;
  Example(ConstructorDependency cd) {
    this.cd = cd; //Constructor Dependency Injection
 }
 public setMethodDependency(MethodDependency md) {
    this.md = md; //Method Dependency Injection
 }
 }

If you want a deeper dive into dependency injection in general, check out this excellent talk by Dan Lew, which in fact inspired this overview.

On Android, when we need a framework to handle the specific problem of dependency injection, we have different options, and the most famous one is Dagger 2. It was originally developed by some great developers at Square, and then slowly evolved into Google itself. The first one to be developed was Dagger 1, and then Big G took over the project and released the second version, making many changes, such as being based on annotations and completing its tasks at compile time.

Importing the Framework

Installing Dagger is not difficult, but you need to import the android-apt plugin by adding its dependency to the build.gradle file in the root directory of the project:

 buildscript{
 ...
 dependencies{
 ...
    classpath 'com.neenbedankt.gradle.plugins:android-apt:1.8'
 }
 }

Then, we need to apply the android-apt plugin to the project build.gradle file, at the top of the file, just below the line where Android application is written:

 apply plugin: 'com.neenbedankt.android-apt'

At this point, we just need to add the dependency, and then we can use the library and its annotations:

 dependencies{
 ...
    compile 'com.google.dagger:dagger:2.6'
    apt 'com.google.dagger:dagger-compiler:2.6'
    provided 'javax.annotation:jsr250-api:1.0'
 }

The last dependency needs to be added because @Generated annotation is not available in Android yet, but it is a native Java annotation.

Dagger Module

To inject dependencies, we first need to tell the framework what we can provide (such as context) and how specific objects should be created. To accomplish the injection, we annotate a special class with the @Module annotation (so that Dagger can recognize it), look for methods annotated with @Provide, and generate a graph that can return the objects we requested.

Look at the example below, where we create a module that returns us the ConnectivityManager, so we pass the Context object to the constructor of this module.

 @Module
 public class ApplicationModule {
  private final Context context;
 public ApplicationModule(Context context) {
 this.context = context;
 }
 @Provides @Singleton
 public Context providesContext() {
 return context;
 }
 @Provides @Singleton
 public ConnectivityManager providesConnectivityManager(Context context) {
 return (ConnectivityManager) context.getSystemService(Context.CONNECTIVITY_SERVICE);
 }
 }

One of the interesting things about Dagger is that you can simply annotate a method to provide a singleton that handles all the problems inherited from Java.

Components

When we have a module, we need to tell Dagger where we want to inject dependencies: We do dependency injection in a component, which is a special annotated interface that we create. We create different methods in this interface, and the parameters of the interface are the classes where we want to inject dependencies.

Here's an example of telling Dagger that we want the MainActivity class to accept a ConnectivityManager (or other dependency in the graph). We just do something like this:

 @Singleton
 @Component(modules = {ApplicationModule.class})
 public interface ApplicationComponent {
  void inject(MainActivity activity);
 }

As we can see, the @Component annotation has several parameters, one of which is an array of supported modules, representing the dependencies it can provide. This can be either Context or ConnectivityManager, as they are declared in the ApplicationModule class.

usage

At this point, what we need to do is create the component as soon as possible (for example, in the onCreate phase of the application) and return it, so that the class can use it to inject dependencies:

In order for the framework to automatically generate DaggerApplicationComponent, we need to build the project so that Dagger can scan our code and generate the parts we need.

In MainActivity, the two things we have to do are annotate the properties we want to inject with the @Inject annotation, call the method we declared in the ApplicationComponent interface (please note that the latter part will vary depending on the type of injection we use, but we will ignore it for simplicity here), and then the dependencies will be injected and we can use them freely:

 public class MainActivity extends AppCompatActivity {
 @Inject
  ConnectivityManager manager;
 @Override
  protected void onCreate(Bundle savedInstanceState) {
 ...
    ((App) getApplication()).getComponent().inject(this);
 }
 }

Summarize

Of course, we could inject dependencies manually and manage all the different objects, but Dagger removes a lot of the “noise” like boilerplate and gives us useful additions (like Singletons) that would be awful to handle in Java alone.