 Good morning all and yeah. So, glide how many of us are already aware of glide great. So, glide is as we all know actually most of us know image processing library and glide on top of many other image processing libraries provide support for this animation and glide allows plenty of configurations that you can do right and it is maintained by Google actually Googlers actually Google great and glide is a library which is used in many popular apps and it is open sourced it is used in Google I O open source app this used in Google photos which is probably your default gallery which you have disabled which is used by us. So, I work for a company name Daily Hunt. So, it is used extensively by us for rate of image processing. So, let us do some data collection how many of you use glide for your projects ok how many of you use Picasso what else you guys are using some of you did not even raise your hand are you guys using any image processing library or it is like a pure text app that you are writing ok. So, how many of you have heard about glide I mean not from this talk before fine I think except for some of us who are really focused on their laptop many of us have used. So, that is why I start up talking about gradle not glide today. So, this is something which we have heard as well it just that gradle never hears as screaming at it. So, yeah let us talk about gradle and why did I spend the two minutes in talking about glide. So, these two have some common steps they are extremely configurable and they have so much of functionalities that you can use in your app which actually both are same although they call those as two different features by both of them and glide actually has a large code base that I can use as a experimental no rat for explaining gradle. So, that is why no I just wanted to know if people had already known about glide and I did not want to scare you people with gradle slide in the beginning great. So, what is this list this is actually the list of modules that is there in the source code of glide. So, why am I listing this you are going to see these terms here and there. So, you do not have to remember now I mean we do not have to remember anything in android we can Google. But this is a link which probably you might want to refer later because the fourth version of glide source code with some improvements I would say some deviations gradle I mean glide team would say are done. So, some of the scripts that we will see from here till the end of the talk are me finding will be here in this link great. So, on that note let us get started the first important thing how many of you break your code. So, how many of you develop. So, how many of you have developed without breaking anything in your app actually nobody raised their hand great. So, every android project usually starts like this we create one module we create one package we create one Java file actually we do not and write this we just create a new project and this how we start and then what we do we just go crazy we add more Java file we add more packages we realize that it is not enough we add more modules and what point of them it is our project there is a module which is actually copy legacy code there is a module which is later screen which is later screen one I do not know which is latest we just have different names for those modules in our code actually they mean this that is exactly the case. So, what happens in this code is module ownership is a challenge it is like nobody knows who owns which part of the code please do not lie to me that in your team everybody knows who is what is their ownership boundary at least your manager do not want you to know that boundary and code reviews become difficult because there are so many things in one project that if you have to make some changes and then see whether your architecture and design are still intact becomes difficult right and known. So, what do we do actually Gradle is actually the problem and Gradle is also the solution. So, what you can do is you can create multiple smaller projects from your project this will need your code to be clean. So, before asking me a question what if my project is not know breakable into multiple modules please go and refactor. So, you should be able to break your big large project into smaller modules or smaller set of modules right and instead of creating cross dependencies you just upload them into a local main and repository I am not showing the code here for this one because it is a custom task which actually you can just copy paste from Gradle which we know how to do we have to just search in stack overflow and you will get it and then you have to copy paste and it works and instead of referencing your dependencies as modules dependencies can be referenced as I know remote dependencies like you would do for a library which is actually available from some remote play or server may one j center whatever. So, once again this is same image which I showed before this is the original glide case and then that is the segment from Gradle script where actually we have the dependency shown and there is a blue highlight and the dependency side where you see compile project library is the dependency of Flickr. So, this is Flickr's modules build up Gradle and it has a direct dependency on library. So, this actually causes all other modules to be required for Flickr to compile how do we break it. So, you just move only Flickr stuff out and compile an error screen at you and then you realize that remaining things are required you just create another project for this and creating another project for it is as simple as just creating another settings that Gradle and copy pasting only required stuff which we do well every day and the end structure what happens is you actually have two projects one project on the left which has only three modules and other project on the right essentially has all other library stuff and here there is a change in the dependencies we have now instead of linking or putting a dependency for the library module we are now putting a dependency for the glide library directly. Actually this sample of should have been like this, but somehow they decided to put it like a direct dependency on their library. So, now what happens is when you are building Flickr app you are most probably going to rebuild only three modules even if you are you know scripts have some issue or something like that. Reminding the stuff the stuff are going to be kept aside. Honestly if you go through your code and then go through your release cycle and the changes that you have made in your code most of the time our code will remain constant for I mean 80 percent of our code will remain untouched partially because there is no change required partially because we are afraid whether it will break something else more for the second reason. So, that 80 percent of the code you can just move it to a separate project and then keep it there and you have to just add those stack overflow copied you know may when uploading a script and then it will just upload and then you can use. So, I am actually directly accessing glide dependency here because I did not set up a specific J center for this one, but you can easily do that with your just you can dedicate one system for that and then it will work because unless you are you are open sourcing your apps code which will probably get you in trouble do not do that unless you are no team say so. It is ok to do this you can just keep one system in the corner of your you know floor and then it will become your you know J center server great. Second item is composite bills. So, this is something relatively new and because it is not like a project structure which we all have talked about I thought of searching in net to find out something which we can show in this game. I promise you just open your Chrome browser and then search for composite build and the images image search result shows this as the first one. I do not know whether Gradle team was playing a practical joke on us when they call that feature composite build, but actually the feature is not this ugly. The composite build feature is like a very intelligent input. It is a composite build is simply a build that includes other bills. This is taken from Gradle site and this simple line actually makes the thing what we did in the previous slide very easy. So, if you see in our case we had the previous slide where two projects are created from a single project. Unfortunately, when you want to build your CI you would not want to build two things separately and then clubbing them together or use J center for every build. I mean it will be crazy if CI has to first build one project and then upload everything to Maven and then build another project using that dependency. So, for that case you have composite build. So, the settings that Gradle is as simple as this. You have to just say these are the two projects and then you have to it is just including build library including build app and then it works. There are some caveats. There are some advantages. We will just have a look. So, there is a catch here actually if you see if you just do this you are earlier case of dependency being directly relying on the module will come into picture because otherwise you will once again go through the J center and Maven loop. Okay. Composite build actually helps composing multiple builds. Obviously, the advantage and it is very useful for large projects. Please do not apply it on a small project. I do not know. I think they are warning us that do not apply it on a small project. But there are couple of negative things. One it is recently introduced. So, it is available only from Gradle 3. So, if you are going to take a chance and it is going to become probably a standard in few months but till then you have to set your CI build Gradle setup to be pointing to 3.x version. 3.1 I think it is stable for composite and which also means that it is not yet supported in another studio. I think it is already supported in IntelJ idea. I do not have idea about that. So, if you have installed IntelJ idea please go and explore the homework for you and declaring dependency. So, the problem which I just mentioned where if you are going for this setup you do not if you do not want to really read the dependency every time from your local J center or Maven for your CI build. Maybe for your developer build you will be taking from there because you will not be building your library project regularly but for the CI build probably we have to manage it in a different way and that is declaring dependencies. So, in a module this is a good old way of declaring dependency where we just write compile and then say so and so version number and the recently suggested ways are to do this. So, you create those versions as a separate constants in your root build.gradle and use only those constants here. So, I am a Java developer not groovy developer. So, I will be using terms which are actually from its constant is not even Java actually C. Okay, but this is I do not know what is the name of that one in groovy. It is functional programming everything is final anyways and dependency.gradle. So, this is the approach that we should do if we are going by that approach unfortunately. So, you have to create one separate dependency.gradle and then create a series of dependency names and then the definition. What is the difference? We will if you see the case of this dependency.gradle this is associated with one of the projects. So, if you are if you are dev setup is having this dependency.gradle and if it is having everything included or imported as remote dependencies. Similarly, you can create another dependency.gradle for your CI setup and there you can actually directly import or create dependency for your project modules using direct module names or otherwise you can go for any other approach. So, there are some other things which we can do if we are keeping this separately and the difference here is you are keeping the full name of the library separately and this also has an advantage and disadvantage. Advantage every not just version update even the library update is kept in one place all your dependency libraries are lying in one place you are just picking and using whichever you want in your individual modules. So, you can easily go and check what all your dependencies and update them, but there is another advantage that no off-lib. So, for example, if you are using Crashlytics or any other such no stuffs which you would probably need only in field in this dev dependency.gradle instead of pointing to the original dependency you can point to some local dependency which you have made as a no off stuff more like a mock of that library. And effectively you will probably avoid this causing a delay in your build time as well as this causing some random analytics data generated in your server. That is the advantage of this dependency model and one there is disadvantages if you use this way. So, if you see the first two options we can actually see the updates being shown as warning here. So, the yellow mark actually says there is an update for you, but here actually will not see it because it is becoming more like a string it does not work that way. Going to the next one it is about securing passwords. Passwords mostly things related to your key store and why would you do that? There may be a scenario where teams are working from different sites and you do not know what is the security level measure that is maintained everywhere and there could be freelancers who are coming in only for few days. It is not that we do not trust freelancers, it is just that human error is possible where somebody unknowingly post it in their Facebook wall and some might return from US and then join your team. This can happen very, I mean with the current scenario I would not be surprised if and load password from environment. This is the solution to that problem. So, do not keep your password in your code base, do not check in into your string, do not keep it as a parameter in your build command because that means you have to give it to everyone voluntarily. So, it is just that in your CI server, hoping your CI server is actually admin protected and you have only access, keep it in the environment variables of that server and then read it from there. There are few four, five lines but actually the key is that system.getenv of any constant that you want to access. And if you are using Jenkins, which is the only CI server that I know, I have used. So, you can actually directly set it in the configuration page itself and if you are having that protected with accounts then you are fine. You do not have to expose your key store password to many people. Flavor dimension, this is more, many of us have used flavor. I think I am sure if you are having a version which is for free, which is another app version for paid, you would have used it. If you are supporting multiple language where you create different apps for different language, you might have used it. Or in our case, we are having different configuration for QA, DAO and other things. So, there we are actually using it. So, the advantage of adding dimension is you can mix and match. So, if you are having multiple variations of app with multiple flavors, then you can actually mix and match. So, essentially, there are three flavors, QA, staging and production and I want to provide a log enabled and log disabled build for both. Then I can just add one dimension. Actually it is barely visible on the top. So, I have added one more dimension log and then I am just adding them and it works. So, that is the way to do it. And it is very simple to do in terms of configuration and it is very less configuration. And it will actually inherit most of the basic properties from the other things. And it can increase the negative part being it can increase the build time. So, you can exclude redundant combinations by using this script. I do not want to go into the script. You can copy paste and it will work. Gradle talk cannot complete without talking about build performance. So, as a customary, I have included this. But I do not want to go through the full optimization procedure. We will just concentrate on few things. Measurement. We all know about, I think many of us would have used this. iPhone, iPhone profile, if you just add it to your Android Studio, it works, right? And it does not. Because you have different developers using different type of machines. You have to ask each and every one to do this and then take the data and then find out. The other way around is to use build scan plugin. Once again, it is very easy to integrate. You have to just include this in your root build at Gradle Networks and optimize it. I am not going through the multiple optimization procedure. I have just given some, you know, kind of tips or probably suggestions. Please set up your Dexing process. No pre-dex libraries and other things falls in your CA configuration because sometimes in rare cases you might get a build created which is not actually in line with what you would actually want from your code. So the reusing, caching and other things, there can be a remote possibility of something going wrong. So please don't do that. And in Gradle properties, once again, in the top one is actually CA, the bottom one is actually dev. So you set according to the server. Don't keep one common logic for all the dev setup or whatever you are using in your dev and whatever you are using in CA. CA might have more RAM. CA might not have more RAM. So please have separate files and then set accordingly. And once again, the parallel and enable build cache, once again, they are also kept false in CA just to ensure that you don't have to do that, right? You don't want a thing repeating. I just want to remind the title again because the next item says don't use Gradle. The effective way to use Gradle is not to use Gradle. But how to do that? Use Buck. You don't want to create new setup again. And for that reason, there is a plugin OKBuck. It's very easy to integrate. Once again, you have to copy paste this in your root.gradle and then when you run again, it will create stuffs. You are using Gradle to kill itself actually. So you are using Gradle plugin to create buck rules. And Gradle plugin to generate, sorry, it's a buck wrapper which is getting created from the Gradle plugin. It is many times faster than Gradle. This is what is claimed. I didn't give any number because it will change depending on your configuration and stuffs. It didn't even work for me first. And I had to write it out to make it work. It's still under development. It's actively developed. That is there. One case is it's not supported by Google. Maybe because it is not in feature parity with other things. I mean Gradle yet. So okay, once you have done this, like once you have applied this plugin and once you have created OKBuck rules, what is that going to happen for your Gradle scripts? You have written a lot of Gradle scripts till then and what is going to happen to that? They are going to be as valuable as this 500 rupees note. Actually, each and every 500 rupees note is now as valuable as this photo. So on that note, literally, I don't know whether I have... Yeah, we have couple of minutes for any questions. Someone there, brave soul. In the meantime, you can look at those links. LinkedIn is my Facebook and your story went crazy some day and writer wrote a story about me. So Haroon, I have a question. Awesome. You talked about dependency.grad where you wrote external equal to something and then you use that. But the problem with that approach is if you make a change there, like when you make change in Gradle file, it shows you auto sync option. But if you make change in dependency.gradle, like if you push it remotely and you pull it, like any dependency.gradle change, it does not show you auto sync. Is there a way to enable auto sync for that file? So for our case, we haven't actually found a way to do that. But how I had managed in our case was just to... I mean, most of the time in our build, in CI, it's going to be a clean build. And this dependency change happens in CI as well as Dev. Yeah. And it's more of a manual process where we just say, okay, sync once and things like that. But there is, as you said, it's again another case where it doesn't work well with Android Studio. That is the problem. Yeah. That's the issue. Like I mean... It's there. It's very much there. Good. If you solve it, please let us know. Any other questions? Good then. So everything understood or nothing was clear. Thank you guys.