Menu
I know that Dagger is a dependency injection framework, but I have not still used it in my projects.
I am starting a new project and wondering if Dagger is suitable for it. As far as I understand, using of Dagger leads to a lot of boilerplate code and annotations. So I am not sure if it is not an overkill for my relatively simple project.
A bit about the project. It is focused on image processing and main part of functionality is built around it. However, it will also probably have a simple backend for data storage.
In general, I would like to know some basic principles that I can use to choose using Dagger for a project or not.
810
Dagger generates code similar to what you would have written manually. Internally, Dagger creates a graph of objects that it can reference to find the way to provide an instance of a class. For every class in the graph, Dagger generates a factory-type class that it uses internally to get instances of that type.
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.
It facilitates the management of complex dependencies. It simplifies unit testing by allowing us to pass all external dependencies so that we can easily use mocked objects. It easily manages the object's scope (lifecycle). This is why we need to use a Dependency Injection Framework in Android, such as Dagger.
It's officially deprecated and you can pretty much ignore it. Google's framework, which became dominant in Android ecosystem, was originally called Dagger 2. Sometimes we still refer to it as such, but, in most cases, we simply call it Dagger today.
Basic Understanding:
Suppose, you want to test your application that deals with Credit Card service. For testing purpose you must not want to Access a real RPCCreditCardService as it will need real transaction and other stuffs that you don't want to perform during development. In that case you must had to create a clone fake service that will mimic the same thing that real CreditCardService does but not transact anything. If you use the dependency injection framework you can define common tasks in a dependency and inject it in both fake and real service. It will minimize coding complexity as well as helps to make each module independent.
From the documentation:
By using dependency injection framework, each class is easy to test. You don't need a bunch of boilerplate just to swap the RpcCreditCardService out for a FakeCreditCardService.
Dependency injection isn't just for testing. It also makes it easy to create reusable, interchangeable modules. You can share the same AuthenticationModule across all of your apps. And you can run DevLoggingModule during development and ProdLoggingModule in production to get the right behavior in each situation.
Reference:
For more detailed understanding you can check this discussion.
178
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
