 Yeah, hello guys. I'm Gaurav Ashish. I work at Fueled. Fueled is, we at Fueled make awesome apps and yeah, so some of the apps which we have worked on in the past are QuizUp. I guess many of you guys have played QuizUp on your Android phone or we have made Afterlight image editing app. It's a competitor to Vasco GAM, VSU GAM and something like that and we make apps every, like we generate apps every month. So yeah, and like recently I've worked on a navigation app called Valk. So in the past some years, like we have been, we have been learning. Hello. Yeah. So yeah, and in the past some years, we have learned various libraries which make our Android development faster and easier and like help our clients to like manage the apps after we have, we have, we are done with them. So like some of the apps are some of the libraries which some of the libraries which we use are like reactive Java or like butter knife or retrofit and and like and dagger. So like today I'll be presenting like how we use dagger to make our development work easier. So dagger is a dependency injection library. So like if, if we don't have a dependency injection in our applications, so our apps will be our code would be something like this. So if, if we are using a dependency in our client class, so we will be, if we don't have a dependency injection, we will be creating its instance inside, inside that class. So this approach has various problems. Like, like, what, what if someone adds another, another constrictor parameter to this dependency class. So if that happens, you would have to refactor your client code too. And, and it may happen that there are, there may be various client classes which are using that dependency. So the refactoring would have to be done in, in, in all of those client classes, like something like, like this or like, but if you want a single instance of that dependency class in, in, in your, all your client classes. So then also you would have to refactor, you would, you would make some factory class to instantiate that, that singleton. And then you would have to refactor all your client classes. So, so what, what we can do is that instead of, instead of the client classes instantiating those objects, like they, those can be given from outside some, some, like from, from somewhere else. So a very simple dependency as very simple definition of dependency injection is like, it means giving an, giving an object its instance variable. And this is what exact dependency injection is. It's a very small definition. So like if you see Wikipedia, so you will, you can learn, you can see longer definitions like, like this in software engineering, dependency injection is a software design pattern which works with inversion of control for resolving dependencies. So you pass the dependencies to the client and you don't let your clients to build or find the dependency. So this is the fundamental requirement of the inversion of the pattern. So if in those, that previous class, you had dependency injection. So like either you would have those, you could have injected them through your constructor or like you could have injected them through a method. Okay. And like there would be some injector classes which would, which would, which would give that dependency to your, your client classes or like there are some dependency injection libraries. So which, by which you use some kind of annotations which, which can, which can do the, which automates that process a little. So I gave this slide just for letting you know that there are three types of injections. One is field injection. You, you can, yeah, you can like instantiate, you can inject a field or you can inject through your constructor or you can inject through your method. So the, like I have previously told the, like the advantages of dependency injections are like that client wouldn't have to know how the dependencies are constructed. So your, your, your client and your dependency classes are decoupled. So this will always, this will always help you to like change the implementation of your dependencies. Like you can then refactor your code a lot faster. And like sometimes while you are writing testing, while you're testing your, your clients. So you can, you can change the, you can change the implementation of your, of your dependency class. This makes your testing a lot, a lot easier. So how can you use the dependency injection? So either you write the injection code yourself. You, you would have to write the injector classes yourself or you can use dependency injection libraries. So some of the dependency injection libraries are like spring, spring is a, it's spring is used for web app development. So like it isn't, it won't be used in Android. So, and one is Google juice. So then like in in the early years of Android development, people tried to use Google juice in, in, in Android, but it was a very large, very large library. And and it used reflection a lot and like it was very slow. And yeah, because of the large, if you use it in like an, if you use this Google juice now, so you will, you will get that dreaded method limit exceeded an exception. So like in 2012, 2013, I, I, I used Robo juice in my applications. So it was an implementation of Google juice by, by Mike Burton and like some, some guys at, I don't remember the company. So it was, it was just like Google juice. It was a small, it was small library, but it was slow as Google juice was. So like a year or two ago, like you would have heard that like Facebook enhanced their messenger app. And in their comments, they had written that they had used a slow dependency injection library. And I know that was this one. So like if you go to Stack Overflow or like if you see the comments on internet, if like you will see that people in the previous years, people like the disapproved of using dependency in libraries because all of them were very slow. So, so to tackle that problem, people came up with the dagger. The square guys, the square gives us, everyone knows that they give us a lot of libraries to use. So they came up with dagger. So we, so we have, we had, we used dagger in, in many applications. So dagger was faster than the previous alternatives. So yeah, it was faster than the previous alternative. It was easy to use. You can use the add data of inject and like an annotations to like, you can get the access to the share instance very easily. You just write add data of inject in your activity or anywhere and you can like get that shared instance without me having, without even having to make factory classes yourselves. And you can replace the modules which, which helped in like, I'll go through modules in, in some minutes. So like, which helped you in, in testing that. So, but there were some issues with the dependency with dagger one. So like the graph composition is, is done at, is it, is done at, then you, when the app is running in, on your device. So like, so like if you, if you're doing that graph to composition in, in your, in your own create of application. So it, it took some time to your, your, your app to start up. And also another problem with that was that if you have done any errors in, in dagger, in configuring dagger, you will get to know about them only when you run the app. So like, so that this was a, like you would have to run and wait for like two, three minutes to, for the app to compile and then you'll know that it was an issue. Also, like there were pro guard configuration issues, you would, you would have to, you would have to various configuration to check what to include or what not to include. Okay. And also the, the generated code by dagger one was like, it was hard to understand for us. And like it used reflection. So you wouldn't know what is happening. It would be, it would be some, it would be difficult. So, so the Google guys took this project from them. Like there are right now, if you search for dagger, you will in the GitHub, you will see one repository is by square and one by Google. So dagger two is the newer one. So it, it, it was a lot faster. It is a lot faster than this dagger one as the graph combustion happens at the run time. So there were, there are no issues with performance. And also you will know the error while you are writing that. So, so like, so you can, you can fix them at the time you are writing the code. Okay. Also, like you won't require pro guard configurations with dagger two. And also generated code is easier to understand. You can, you can just go through their generated classes and like, you will see that it is something which you would also write yourselves. So, like how many, how many of us have used like no dependence injection before? How many of us no dependence injection? Okay. Like a lot of them, you know, so like those who haven't used and how many of us have used dagger? Okay. So those of you haven't used dagger, you will see if you it will be very easy, it will become very easy to for you to access the shared instances, you will in your activity, in your activity, you will write at the rate of instance and at the rate of injects and the class and in the some field name and you can get to use it and without having to write any code for that any factory method for that instance. So, like in in dagger two, you can have application wide shared instances like a singleton will be the scope of a singleton can be like from the, from the start of the active of the app and to the end of the app. Or you can also have activity wide shared instances, like if you if you instantiate an object in your activity, so then you can have that same instance in your fragments or any like, like, like some like my colleagues use MVP pattern. So in their presenters, they can, they can always use their instances, which we created in their activity. Also like another another advantage of it is like, while like I can mock, I can mock many things while I'm testing that like I can mock my JSON responses, which are, which are coming from the server or like I can use various components different. I can use different modules to be used in different flavors. So like dagger two helps me in like in in these things. Yeah. Okay. So this is just so this is just like it simplifies access to the shared instances shared instances can be scoped and like you can replace module for easier testing. So this is for like simplify access to shared instances, you can write this inject this API client inject this four square API client and then you can use it use these in your in your activities. So this is this was why why we use dagger two. So now I will be coming up with like how do you write the code for dagger. So so some dagger two uses annotations for for everything. So first and foremost, annotation is added to injects. It tells dagger to inject a dependency. So we have three kinds of injection field injection constructor injection and method injections. So you can do in your activities, you can use field field injection if you can. So you can like as I had already told you these this field injection. And besides this, you can have constructor injection, but not activities or your fragments or your services because you can't you can't access their you shouldn't access their constructors. So you can't have constructor injection in activities, but you can have them in in your different different classes like like I made a like for example, I made a data store which which wants to show an instance of shared preferences. So I can have it in your in its constructor. And another one is method injection. So it's so so the it it is it is useful. It is useful for then field injection. Because in the field injection, though, you can't make the fields private. But with method injection, you think you can have private fields. And yeah, another ingredient is at the rate of module. So you you annotate a class with at the rate of module and annotation and and that can contain methods which which provides the instant your your dependencies to your clients. So it contains it. It's a class annotated with that data module and it contains provider methods. So the as you see in the earlier slide or dislike, so you can have methods and you can annotate them with at the rate of provides and you can have any name. The name of the method doesn't it doesn't count. You can write anything. So in now, if you have this module, and if you are in your activity or anywhere, you write at the rate of inject converter factory, this this instance will be given to that. And it's a it's a standard of singleton. So like it will have if you if you construct this module in your application, so this will be singleton for your whole application. And this is the component. It's it's a it's a it's an interface. So you you annotate your interface with component and you tell it which module to use. So as you can see, you can you can change this module like okay, so you can change this module and and you also write inject methods. It should be void inject and and the in the client classes which want to which want to use the dependencies provided in API in the in your module. So there's another thing and then another like as I had told before, you can have your singletons, you can have a shame instances for like which can which can last the entire application lifecycle or like or or the activity lifecycle or like I've given this I've made this diagram. So if if a singleton if instance is for is for application scope will run for the whole application or if it's just for the activity scope, it will it will be just it will just there for that activity. Or you can have custom scopes like user session and all. So like for for making a scope you make a new you make a new annotation and you annotate with at the rate of scope. And you can know this can be now know you can have a new module which can have like in the previous one we had at the rate of singleton. So here you will have this activity scope. So if you if you will start if you will like start this it's the if if a component is initialized in the start of an activity in on greater than activity. So this this activity will be there just for this instance will be there just for the for that activity. It will be like in the on destroy you can you can destroy that that component. So I can do the at time. Okay. So I have a small example or do we do you want to ask questions? Hi, so I just wanted to know like does it maintain the like if you make your application gone in the background from home press and then later if Android system recognize that this was the last fragment which was there and it just pop up that fragment. So will that inject will get give that data so that would be able to get that object or not. So if you have initialized your if you have initialized your component in your application so it will be there till that application is not destroyed. So if my question is so if if you're saying that if it comes from from your task list, then before that your application class would be run and that that component will be made again. If it has gone from the it has it it has gone then it won't come back. So what would be the default value that would be holding like would it store the value that is had at the last time? Like if it starts again, then it will it will run that it will run your application on create again. So like and you will get a new instance. And if you want to save that then you would have to use your like SQLite or something to persisting the data, then you would have to use something. So it won't persist your data across the application. Okay, I don't think we have time for any more questions. So anything else we can take it offline.