First of all, you need Dependency Injection Framework .If you don't need Dependency Injection ,you needn't Dagger2 either. Second,You need Dependency Injection Frameworks which implement the full stack with generated code rather than reflaction-based. That's all. The benifit of DI I don't want to Say.
I've been using Spring for some years and am now favoring Dagger 1 whenever possible. Dagger 2 seems fantastic, but please, don't show outdated Spring examples. You don't need that to prove your point :-)
It's easy to see how and why Dagger 2 is better than the others. What is not easy though is to learn how to implement, because the documentation isn't straightforward to new comers.
I would love to see a talk on how you do unit testing in Dagger2 projects. The ressources on the web are rather scarce - more questions than answers - most of them don't seem to be very satisfying. There don't seem to be best practices.
+brixomatic Same here, I am currently evaluating Dagger2 vs Roboguice for a new Android project and quite frankly I am thorn between the two. I really like the compile-time validation and traceability of Dagger2, but so far I was not able to figure out how to override modules for instrumentation tests in a nice way. Specifically, I would like to run some Espresso tests and I would like to mock some of the business logic access interfaces. With Guice it is pretty straightforward, but not with Dagger2. If anyone can tip me off, I would really appreciate:-)
brixomatic I ended up injecting the Component itself "the old way" with an eagerly initialized singleton. In the test I can initialize the singleton with a Component, which is built using a subclass of my Module. ModuleSubclass simply extends the Module overriding the methods I want thus letting me use mocks for specific dependencies.
Guice still works great, and has more complete documentation. Not really sold on generating code, and I never had issues with Guice errors... Like you said, the "magic" of reflection its just better.
+Nishad Gurav it's frowned upon in this case (not universally) because it's managed separately from the Java code, so developers had to configure their Dependency Injection in two different places.
Zg Programeri lol that’s not true. It’s annoying to look at something like html just to understand how the DI is working. There’s many ways nowadays to remove that annoying overhead.
in the past, i've had terrible experiences with $ filenames.. on Linux you end up having to escape them so the shell doesn't try to interpret them as a var.
In the entire 40 minutes of this video, all he explained was how Dagger 2 was better than the rest. So basically if I am new to this Dagger world and want to enter it, this video is totally useless. Maybe the whole intention of the talk was different, but clearly it doesn't really serve any purpose.
Here's an idea, it might be a bit crazy What about making a dependency injection framework that uses reflection to generate the dependency injection at compile time. IMPOSSIBLE! I hear you say Well, kinda. Except if you have the code generate java code that is then run through a compiler again. That way all the dependency injection generation happens during the code generation step, but the fully compiled application will never see or feel any of this. Sure, this is gonna be worthless for servers that do this stuff dynamically, but it would probably work fine for other types of applications. The only major downside, is increased compilation time.
docs.google.com/presentation/d/1fby5VeGU9CN8zjw4lAb2QPPsKRxx6mSwCe9q7ECNSJQ/pub?start=false&loop=false&delayms=3000&slide=id.p The slides of this talk.
Can someone tell me why the code in ruclips.net/video/oK_XtfXPkqw/видео.html ? As he explained the dependency injection before he shows that code, it seems that there's no need for DI frameworks. I'd like to know where that code came from.
sorry but the introduction to DI was really disappointing, mainly because the most important use case - inversion of control - wasn't even mentioned, but also the comparison of how the code is like without DI isn't really accurate imo, we don't always need factories for object instantiation and most of the time it's pretty straightforward where to instantiate them and it's kinda scattered all over the place, not like what was shown.
may God bless you lol may God bless us lol I love everybody godly probably love please excuse me for being lovely just got service u-haul my father and her then Jesus Christ His only begotten Son I blast myself Father and Son and Holy Spirit by saying hallelujah amen Jesus name may God bless us USA. the only other countries in the world all of us lol
A couple nit-picky things before my real comments: He could use some humility. "I feel bad calling it ugly; I had a hand in writing some of it" at 23:35 and "I'm a great software engineer, I've got this" at 5:25 really has him coming off as a little arrogant. The fact that I don't see any Dagger 2 stuff until after he's spent 25 minutes picking apart the existing DI frameworks was a little off putting to me as well. I'd rather you spend that 25 minutes giving us a bit more detail on how Dagger 2 works. You could spend 5 or 10 minutes explaining why Dagger 2 is better than the rest, in a simple overview/comparison chat and move on. Instead, it felt like they had to pull an Apple, and tell me how horrible everything else was and that they're stuff has solved all of the worlds problem. Dependency Injection started much earlier than 2002. Perhaps for Java it was 2002; in general though, DI has existed since the late 80's/early 90's. This is not something that came out of nowhere in the early 2000's. My comments on the framework: The concept looks nice. I'm not a Java dev, so I'm not qualified to critique the framework. Having said that however, I'm not a big fan of taking on a dependency of @Inject and the other attributes throughout your code. If you ever want to migrate away, it makes it a real pain. One of the goals of DI (far from the only goal) is to allow you to swap out components with minimal effort. By decorating everything in your app with the Dagger attributes, you become tightly coupled to it. You can swap out your components easily, at the expense of tying yourself tightly to the DI framework. He mentions that they are currently migrating a huge application off of Guice and it's not something that can be automated. That means there's to many dependencies on how the injection happens. Again, I'm not a Java developer; I assume the attributes are used due to a language or framework constraint. In .NET, I set up DI at the top-most level. Everything in the app gets constructor injected with zero dependencies through-out all of the layers of the application. We swapped out DI in an app with over 500,000 LoC in 3 hours, because the DI was set up in a single class of 60 LoC, at the top most layer. It's to bad that this doesn't seem to be available in Java yet. While we used an IoC container to handle the injection, the client/dependent objects didn't care what was used or how it got it. They just asked for services via the constructor and received them. We can swap out IoC containers, or not use them in favor of DI without a container, and all of the layers that take dependency services won't care. We can mock/fake our dependency services, swap them out as requirements changed etc, and not worry about updating the IoC container or creating new @Modules or factories. I do like that Dagger uses zero reflection. For Mobile, that's a huge (relative) performance penalty.
+Johnathon Sullinger (Sully) You got it wrong. "I'm a great software engineer, I've got this" he wast talking about other developers saying this as an excuse for not using Dependency injection. You took it out of context: "... and some people say 'yeah that's true but I can manage it myself, no really I'm a great software engineer"
+roxferesr Alright, I can concede to that. I still don't see this as a proper DI system. This is nothing more than IoC and abstract factories. Like I said, I'm not a java dev (.net/objective-c) so maybe this is just a limitation of Java. A proper DI system IMO would allow you to register types to a container object. You don't need to build out these quasi factory modules that instantiate everything for you. Using attributes tightly couples your entire code-base to Dagger 2 which is troublesome as well. One of the goals (albeit not the only one) is to help with loose coupling of components so you don't take on hard-dependencies. Using attributes requires your entire code-base to take a hard-dependency on Dagger 2. What happens when Dagger 3 is introduced with a massive perf gain? You have to touch your entire code base, instead of a single location that sets up an abstract DI system that can be hidden behind factories or service locators (service locators are eww too imo tho :/) controlled and owned by the consuming application.
I know this is an old comment, and you may already have heard this elsewhere, but I'll post this for posterity anyway: You mention "... dependency of @Inject and the other attributes ...", @Inject is a part of JSR (Java Specification Request) 330, which was approved, which means the only dependency needed to include them is Java itself. These are also _annotations_ not attributes, which in Java has the added benefit of "if you don't know what they're used for, you can safely ignore them", so if you switch to a framework that doesn't use these annotations, or don't want to use a DI framework at all, you don't have to remove them from your code. You also don't have to use these annotations everywhere in your code for Dagger2 to work, you could write a small method in a dagger "module" that constructs these objects, the @Inject annotation just reduces the amount of boilerplate you need to write, and puts the configuration closer to the relevant code. If other languages are able to provide dependency injection with compile-time validation, no reflection and no need to change preexisting code, cool, I hope those languages manage to influence future Java versions to allow the same.
Brilliant guide. I like the fact that Greg went through the history of DI. It makes everything clear!
Thank you good sir. It's because of people like you in our java community I feel blessed.💗
Explained the need for Dagger 2 , which I think is the most important thing to understand.
First of all, you need Dependency Injection Framework .If you don't need Dependency Injection ,you needn't Dagger2 either.
Second,You need Dependency Injection Frameworks which implement the full stack with generated code rather than reflaction-based.
That's all.
The benifit of DI I don't want to Say.
Who else thinks this guy looks like the main character from The Silicon Valley with a beard.
+iamprasad88 Yes haha
+iamprasad88 just about to comment it
yeah, that's him
I have been thinking this all time, he even speaks like him....
Richard Hendricks.. lol.. a little bit. but not sure Greg would like that.. #middleOut :)
I've been using Spring for some years and am now favoring Dagger 1 whenever possible.
Dagger 2 seems fantastic, but please, don't show outdated Spring examples.
You don't need that to prove your point :-)
My head is about to explode
This is amazing! He needs to do more talks.
It's easy to see how and why Dagger 2 is better than the others. What is not easy though is to learn how to implement, because the documentation isn't straightforward to new comers.
The tutorial is broken and different from Githun :/
I feel like I am watching Robert Pattinson presenting DI! Very engaging.
I would love to see a talk on how you do unit testing in Dagger2 projects. The ressources on the web are rather scarce - more questions than answers - most of them don't seem to be very satisfying. There don't seem to be best practices.
+brixomatic
Same here, I am currently evaluating Dagger2 vs Roboguice for a new Android project and quite frankly I am thorn between the two. I really like the compile-time validation and traceability of Dagger2, but so far I was not able to figure out how to override modules for instrumentation tests in a nice way. Specifically, I would like to run some Espresso tests and I would like to mock some of the business logic access interfaces. With Guice it is pretty straightforward, but not with Dagger2. If anyone can tip me off, I would really appreciate:-)
Yuriy Kulikov If you find something let me know.
brixomatic I ended up injecting the Component itself "the old way" with an eagerly initialized singleton. In the test I can initialize the singleton with a Component, which is built using a subclass of my Module. ModuleSubclass simply extends the Module overriding the methods I want thus letting me use mocks for specific dependencies.
Yuriy Kulikov Sounds like a way to go. I'll give that a shot, thank you.
@@YuriyKulikov You should know that writing mocks is bad for unit tests.
Guice still works great, and has more complete documentation. Not really sold on generating code, and I never had issues with Guice errors...
Like you said, the "magic" of reflection its just better.
Good presentation!
Wow this blew my mind 360
Thanks for this!
Well done jolly JOKER. Your smile is spot on. Fantastic discourse.
Great talk!
lombok is also great for code generation, though few people seem to talk about it in the Android community :/
That's unrealistic because you can make a Java configuration in spring since spring 3! Even though I couldn't disagree with heavyweight of spring!!
Yeah, actually Spring 5 has improved a lot DI configurations and annotations as well ass Java EE, in comparison with older versions.
29:08 not yet :D
What is this, The Sopranos? Don't end something in the middle o
Greate!!!
13% per request CPU improvement, what's dagger2 bench mark with?
What does map-like API mean please?
Any wiki on reflection available?
Can anybody tell me why is XML frowned upon?
+Nishad Gurav it's frowned upon in this case (not universally) because it's managed separately from the Java code, so developers had to configure their Dependency Injection in two different places.
+Nishad Gurav Also because if you made typo mistakes in class names, you would only get to know about it when your app fails to run
Zg Programeri lol that’s not true. It’s annoying to look at something like html just to understand how the DI is working. There’s many ways nowadays to remove that annoying overhead.
To Much Boilerplate in comparison to spring
Use Hilt
Hahahaaaaaaaaaaaaaaaaa......... nice to play.
I can say current Spring is 10 times better than dagger 2 .
in the past, i've had terrible experiences with $ filenames.. on Linux you end up having to escape them so the shell doesn't try to interpret them as a var.
打酱油路过
Tayo
In the entire 40 minutes of this video, all he explained was how Dagger 2 was better than the rest. So basically if I am new to this Dagger world and want to enter it, this video is totally useless. Maybe the whole intention of the talk was different, but clearly it doesn't really serve any purpose.
"All he explained was how Dagger 2 was better than the rest" - maybe that's why he titled the video "DAGGER 2 - A New Type of dependency injection"
+1
Is it a presentation for management who will never code?
If you knew Guice, it could be a different story for you. Guice's pros is motivated to build Dagger 1 and upgrade to 2.
It still says Provide of T :p If you know what I mean :)
Here's an idea, it might be a bit crazy
What about making a dependency injection framework that uses reflection to generate the dependency injection at compile time.
IMPOSSIBLE! I hear you say
Well, kinda. Except if you have the code generate java code that is then run through a compiler again. That way all the dependency injection generation happens during the code generation step, but the fully compiled application will never see or feel any of this.
Sure, this is gonna be worthless for servers that do this stuff dynamically, but it would probably work fine for other types of applications. The only major downside, is increased compilation time.
and how would it know which subclass/interface impl to instantiate and with what instance (singleton or not)?
docs.google.com/presentation/d/1fby5VeGU9CN8zjw4lAb2QPPsKRxx6mSwCe9q7ECNSJQ/pub?start=false&loop=false&delayms=3000&slide=id.p
The slides of this talk.
Can someone tell me why the code in ruclips.net/video/oK_XtfXPkqw/видео.html ? As he explained the dependency injection before he shows that code, it seems that there's no need for DI frameworks. I'd like to know where that code came from.
lol
"as you notices this was no tutorial" ruclips.net/video/oK_XtfXPkqw/видео.htmlm20s
sorry but the introduction to DI was really disappointing, mainly because the most important use case - inversion of control - wasn't even mentioned, but also the comparison of how the code is like without DI isn't really accurate imo, we don't always need factories for object instantiation and most of the time it's pretty straightforward where to instantiate them and it's kinda scattered all over the place, not like what was shown.
may God bless you lol may God bless us lol I love everybody godly probably love please excuse me for being lovely just got service u-haul my father and her then Jesus Christ His only begotten Son I blast myself Father and Son and Holy Spirit by saying hallelujah amen Jesus name may God bless us USA. the only other countries in the world all of us lol
This should be the top comment
Just use vanilla Java. Problem solved.
A couple nit-picky things before my real comments:
He could use some humility. "I feel bad calling it ugly; I had a hand in writing some of it" at 23:35 and "I'm a great software engineer, I've got this" at 5:25 really has him coming off as a little arrogant. The fact that I don't see any Dagger 2 stuff until after he's spent 25 minutes picking apart the existing DI frameworks was a little off putting to me as well. I'd rather you spend that 25 minutes giving us a bit more detail on how Dagger 2 works. You could spend 5 or 10 minutes explaining why Dagger 2 is better than the rest, in a simple overview/comparison chat and move on. Instead, it felt like they had to pull an Apple, and tell me how horrible everything else was and that they're stuff has solved all of the worlds problem.
Dependency Injection started much earlier than 2002. Perhaps for Java it was 2002; in general though, DI has existed since the late 80's/early 90's. This is not something that came out of nowhere in the early 2000's.
My comments on the framework:
The concept looks nice. I'm not a Java dev, so I'm not qualified to critique the framework. Having said that however, I'm not a big fan of taking on a dependency of @Inject and the other attributes throughout your code. If you ever want to migrate away, it makes it a real pain. One of the goals of DI (far from the only goal) is to allow you to swap out components with minimal effort. By decorating everything in your app with the Dagger attributes, you become tightly coupled to it. You can swap out your components easily, at the expense of tying yourself tightly to the DI framework. He mentions that they are currently migrating a huge application off of Guice and it's not something that can be automated. That means there's to many dependencies on how the injection happens.
Again, I'm not a Java developer; I assume the attributes are used due to a language or framework constraint. In .NET, I set up DI at the top-most level. Everything in the app gets constructor injected with zero dependencies through-out all of the layers of the application. We swapped out DI in an app with over 500,000 LoC in 3 hours, because the DI was set up in a single class of 60 LoC, at the top most layer. It's to bad that this doesn't seem to be available in Java yet.
While we used an IoC container to handle the injection, the client/dependent objects didn't care what was used or how it got it. They just asked for services via the constructor and received them. We can swap out IoC containers, or not use them in favor of DI without a container, and all of the layers that take dependency services won't care. We can mock/fake our dependency services, swap them out as requirements changed etc, and not worry about updating the IoC container or creating new @Modules or factories.
I do like that Dagger uses zero reflection. For Mobile, that's a huge (relative) performance penalty.
+Johnathon Sullinger (Sully) You got it wrong. "I'm a great software engineer, I've got this" he wast talking about other developers saying this as an excuse for not using Dependency injection. You took it out of context: "... and some people say 'yeah that's true but I can manage it myself, no really I'm a great software engineer"
+roxferesr Alright, I can concede to that. I still don't see this as a proper DI system. This is nothing more than IoC and abstract factories. Like I said, I'm not a java dev (.net/objective-c) so maybe this is just a limitation of Java. A proper DI system IMO would allow you to register types to a container object. You don't need to build out these quasi factory modules that instantiate everything for you.
Using attributes tightly couples your entire code-base to Dagger 2 which is troublesome as well. One of the goals (albeit not the only one) is to help with loose coupling of components so you don't take on hard-dependencies. Using attributes requires your entire code-base to take a hard-dependency on Dagger 2. What happens when Dagger 3 is introduced with a massive perf gain? You have to touch your entire code base, instead of a single location that sets up an abstract DI system that can be hidden behind factories or service locators (service locators are eww too imo tho :/) controlled and owned by the consuming application.
I know this is an old comment, and you may already have heard this elsewhere, but I'll post this for posterity anyway:
You mention "... dependency of @Inject and the other attributes ...", @Inject is a part of JSR (Java Specification Request) 330, which was approved, which means the only dependency needed to include them is Java itself. These are also _annotations_ not attributes, which in Java has the added benefit of "if you don't know what they're used for, you can safely ignore them", so if you switch to a framework that doesn't use these annotations, or don't want to use a DI framework at all, you don't have to remove them from your code. You also don't have to use these annotations everywhere in your code for Dagger2 to work, you could write a small method in a dagger "module" that constructs these objects, the @Inject annotation just reduces the amount of boilerplate you need to write, and puts the configuration closer to the relevant code.
If other languages are able to provide dependency injection with compile-time validation, no reflection and no need to change preexisting code, cool, I hope those languages manage to influence future Java versions to allow the same.
tldr; Java is a bad language.
Tayo