Menu
I know this may be not the correct way to ask question but after reading lot and lot I am still confused about daggers and how it works and why we should use it. Since its been used in my current working project. Please somebody give me little hint in simple words what is the purpose of dagger will be very helpful.
344
Dagger automatically generates code that mimics the code you would otherwise have hand-written. Because the code is generated at compile time, it's traceable and more performant than other reflection-based solutions such as Guice. Note: Use Hilt for dependency injection on Android.
Dagger is arguably the most used Dependency Injection, or DI, framework for Android. Many Android projects use Dagger to simplify building and providing dependencies across the app. It gives you the ability to create specific scopes, modules, and components, where each forms a piece of a puzzle: The dependency graph.
Dagger is a fully static, compile-time dependency injection framework for Java, Kotlin, and Android. It is an adaptation of an earlier version created by Square and now maintained by Google.
In Android, you usually create a Dagger graph that lives in your application class because you want an instance of the graph to be in memory as long as the app is running. In this way, the graph is attached to the app lifecycle. In some cases, you might also want to have the application context available in the graph.
Dagger is a compile-time JSR-330 dependency injection framework based on Java annotations.
Dependency injection (sometimes termed Inversion of Control or IoC) is based on the idea that a given class should not need to know how to create or provide the classes it depends on. Providing those dependencies should be the responsibility of the class's user (or a separate class or factory).
For example, let's say you have class A that depends on class B, that depends on classes C and D. (In real terms, that might be an Application, that depends on a BusinessLogicClass, that depends on a Calculator and a Database.) It could look like this:
class A { private B b = new B(); } class B { private C c = new C(); private D d = new D(); } ...but at that point it would be really hard to use a different C or D (calculator or database), even your B (business logic class) should work with a variety of data sources, or if you need to replace any of those pieces for unit testing. Dependency injection, as a concept, says that you should be able to pass in dependencies into the classes when you create them.
A a = new A(new B(new C(), new D())); // Now you get an A, but can replace any part of it. A dependency injection framework automatically creates factories for all of your classes, so you can create an A without worrying about its dependencies, or its dependencies' dependencies.
A a = new AFactory().getA(); // Equivalent to the above, but easier! Dependency injection frameworks usually come with a language for you to specify mappings, often called bindings, which is just a way of instructing that you should create a EImpl when a class asks for a EInterface or a FSubclass when a class asks for a FClass. This language also lets you choose when to create new instances: On every request, once across the whole app ("singleton"), or otherwise. Spring uses XML and Guice uses a custom Java class language for this; Dagger uses Java interfaces, classes, and annotations.
You can do dependency injection without a container or framework, but most of the time people think of a framework like Spring, Guice, or Dagger when you mention dependency injection. These frameworks automate away a lot of the new boilerplate you see above, which could otherwise make "manual" dependency injection hard to work with.
Java standardized some interfaces and annotations as "JSR 330" to make it easier to switch between dependency injection frameworks, and to make it easy to write libraries that work in any framework. Like Spring and Guice, Dagger conforms to this standard.
Other dependency injection frameworks, including Spring and Guice, do their configuration at runtime: They use Java reflection to inspect classes' constructors, methods, and fields. This can be slow in production on servers and desktops, and is extremely slow on Android due to both VM differences and mobile processor/memory constraints. Consequently, teams at Square and Google wrote Dagger and Dagger 2 to use Java annotation processing to inspect the classes at compile time and automatically write standard Java code for plain Java objects to act like the factories above. Because this is plain Java without reflection, it can be much faster on Android and embedded systems, and can be optimized using existing tools.
Note, as well, that Dagger was written at Square by Bob Lee (who originally wrote Guice at Google); the Dagger 2 project is rewrite of Dagger maintained at Google that changes some of the specifics about how to configure Dagger and how to avoid using reflection. Both Dagger and Dagger 2 are annotation-based compile-time dependency injection frameworks for Java, but they're slightly different from one another.
137
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
