Modern Dependency Management With Version Catalogs - Android Studio Tutorial 💻

hey guys and welcome back to a new video in this video I will give you a guide on Gradle version catalogs since they become more and more the standard of Gradle dependency management and to get start with these all you really need to do is to create a new empty Android Studio project and here really depends on when you watch this video so as of now where the latest stable Android studio version is Hedgehog version catalogs are not the default yet when you create a new product so if your dependencies in your build.gradle app file look like this where you have just string dependencies right in here then you're not yet using grad version catalog and that also looks like that if you're just using some kind of older project that has been created with an older Android studio version if you're using one of the later Android Studio versions so right now I think in Canary it's iguana or so then Andro St will already use and create such version cataloges by default if you create a new project in either way watch this video so you really understand what these are about and what you need to know in order to use them only if your grad file looks like this and you have your dependencies as simple strings in your grad file then you need to first of all create that version catalog and in end the version catalog is just a catalog of versions of dependencies and the more dependencies you have the more it becomes a pain to manage these and to manage all these different versions because some of your dependencies might actually use the same version if you have multiple dependencies um of the same type for example if you're using kto client for networking that is a typical example you might need a dependency for the for the core of K your client you might need a dependency for the authentication feature you might need a dependenc for logging HTTP calls and all these dependencies are different but they use and refer to the same version and version catalogs just make that very easy to manage that also if you have a product with a multimodule structure we have multiple grader modules and where each single grader module has its own set of dependencies a version catalog allows you to have all your dependencies at a single place which all modules can refer to as a single source of Truth and in the end if we take a look at such a dependency in Android then that always consists of the same parts so on the one hand we have the so-call group which comes before the colon so in this case Android X core or Android X compos UI or junit here that is really just a group of dependencies so a group that bundles multiple related dependencies so you can see here Andro X compos UI and X compos UI and X compos UI all these groups are the same so all these dependencies belong to the same group but they refer to something specific relating to compos UI so this is for the preview this is for probably just normal compos components and that's called the name so what comes after the colon is the name and then lastly after the last colon potentially we have the version of a dependency in this case here we don't have a version specified so that is another way of specifying a dependency because here we use this B which stands for bill of materials which includes all the versions for a specific set of dependencies so in this case um it's a composed B which just combines a specific set of versions for composed dependencies that work well together and if we specify such a b then we don't need to specify the individual versions for all these dependencies that are contained inside of this and that way we just need to update the version for this B in order to update all the dependencies that it includes okay so much about the theory let's now create our very first version catalog and again if your Gradle file does not look like this and you have something like lips. androidx and so on here then you can skip this step but if not you can go to this project view here open your project hiero key and go inside of this Gradle folder because that is where the version cataloges are located in here we want to create a new file so right click new file and we name that lips. versions. TL that is how the default version catalog is actually named We press enter and then in here a version catalog is structured into three parts usually whoops which we introduce with such square brackets on the one hand we have versions block we then have a libraries block and we then have a plugins block So Below this versions block we specify all the versions that we have for our dependency so really just the version 1.7.0 and so on in this libraries block we specify the dependencies we want to use with these versions and in this plugins block we specify the Gradle plugins that we want to use so here in our project file for example the application plugin uh the cotland compiler plugin if you're using dagger Hil or so and that would also go in there and so on for now you can see Gradle wants us to synchronize these changes let's do that click sync now and when that is done when go back to our app level Gradle file because you can see now suddenly everything is highlighted in yellow that means we can do something here we can hover over such a dependency and hit Alt Enter and you can see we can now replace this with a new library catalog declaration hitting enter and that is now how we now specify these dependencies that's currently marked as an error because we need to synchronized that before if we do that then you will notice that the hour will go away there you go and that is now how we really refer to a specific dependency that is specified in our version catalog if we now take a look here in our Libs version Tel file then that is exactly what happened so Studio automatically added the version for our core KTX Library which is 1.12.0 and it also added the Android xcore KTX dependency where it specified the module so the module is just the group together with the name of our dependency and it specified the version reference it should use for that so here we say core KTX because that is how the version for that is called if now multiple dependencies share the same qut KTX version we don't need to Define that multiple times no we can just paste the same uh version reference here for all these dependencies and the version catalog will keep that in sync so if we now go back and also do that for the remaining dependencies here for the life cycle runtime again Alt Enter and ENT studio will create that version catalog reference here Alt Enter again the only dependency that doesn't automatically work for yet is if you have such a bom then you need to create that manually so if we go to our lips. versions We need to scroll up and actually refer or have a version for the composed B version which in this case is exactly this version so we can copy this and paste it in here and then under libraries we specify the composed bill of materials and the name convention for these Library specifications is just exactly like the version is called the dependency is called you can see we have Android X activity activity compose and that's also how this is called so Android X activity composed and whenever there is a dash the version Library will replace that with a DOT when we refer to it here that way we have all dependencies related to uh activities here under lips. Android X activities we have all dependencies related to Android X under lips. Android X and so on so now to specify this B we want to copy this group and name together we go in here and specify our Android a. compose B Al Al open curly braces here specify the module just like above paste this here and we need to now have a comma and refer to the version with version. ref and in this case we want to use our composed bomb version and then in our build. gr app file we can also sync this before so we don't have any syntax errors we can go in here and now replace this dependency in here with lips. Android x. compost. bom when we now want to use a dependency that uses the version specified in the B like here this composed UI dependency we can again copy this go in here have an Android x- compose D UI in this case we only need to specify the group and not the whole module because uh the version is already specified in the B which we've included so here we paste the uh Android a composed. UI without the name so just the whatever comes before the colon and then we say the name is UI as a separate dependency as a separate parameter I mean um but here we don't need to specify the version reference because that is contained um by the already included B and then again back in our app level Gradle file we can now refer to that with ellips uh Android x. compost. UI If We sync this then everything should be just fine let's do this for the remaining compos dependencies for that we can just go to lips. versions can duplicate this one here three more times on the one hand we have our how was it called called UI Graphics UI tooling preview so ui- Graphics here we say okay we have our composed UI that is the same but UI Graphics isn't so again Android X compos UI here we say UI Graphics here we have UI Graphics oops Graphics tooling I think is it written like that tooling preview actually u i tooling pre preview you can see the auto complete is also working here so UI tooling preview then we have one for UI material 3 we say that one is material three we can sync this and then we refer to these versions in our Gradle file again I think the remaining dependencies we can specify directly with the shortcut in interal Studio I hope they actually fix that so we can also easily create that for the B and for dependencies without version but here we can say lips. Android a. compost. ui. Graphics same for the preview lips and X compose UI toing preview and for the material one as well lips Android X compose UI material 3 then we can do junit out enter enter again we can do this for the junit extensions as well we can do this for espresso and now since we used the same B version for our instrumented tests we can just refer to the same reference from our version catalog so lips do um Android x. compost. B and that way we just have a single source of Truth for that single dependency and if that dependency changes the the version for this bomb then this will automatically update the dependency for both the production and the instrumented test APK and here it seems we still need to add three more for instrument testing and for the debu APK so on the one hand we have Android X composed for UI test junit 4 so let's just duplicate this here UI junit 4 paste this here actually UI test- junit 4 we have UI tooling let's put this below the tooling preview so just UI tooling UI tool tooling and lastly we have the UI tooling manifest I think so UI tooling manifest no is it UI test manifest actually UI test manifest sync now refer to these last few dependencies here here it was what was that um UI test J 4 lips Android X junit uh no Android X X UI test what was it called again uh UI test junit for and X composed UI lips andot X compose UI test junit 4 that one it is then we have one for and X compos UI UI tooling and x uh lips and X compos UI tooling and lastly the one for anod X compos UI tooling Manifest this one and that way if we now sync this we successfully migrated all of our dependencies to the new version catalog where we now have a single Source where we can update our dependencies we're not done yet with the video but just to show you here you also get these highlights when there's a new version and you can just hover over it hit Alt Enter to change this version to the latest stable version sync this and it will sync these changes so with all your Gradle modules we refer to the version catalog like we do here and from this point whenever you add a new dependency to your project like here let's say we want to add the extended material icons for compos we say implementation U material icons extended I think it's this one then you just add this you get the Highlight you hit Alt Enter replace with a library version catalog and you get this in your version catalog you click sync now and you're successful fully added the dependency inside of your version catalog however this is not the only place where you have to deal with versions another place is your Gradle project file which is this one where you have your Gradle plugins so you can see the current Gradle version for your app is in this case 8.2.1 so that has a version we have our cotland version which is 1.9.0 in this case so these are also kind of dependencies that need to be managed and luckily that also works with version cataloges for which we can use this plugins tab or this plugins section below our dependencies up here for that there is Sly no such shortcut as we have for dependencies at least yet so we need to just take these copy them over to our lips versions version catalog here and say hey we have an Android application which in this case has an ID and we paste the ID here and we specify the version reference with a new reference we create for example AGP for Android Gradle plug-in we go up here here and create this here AGP version is 8.2.1 so exactly what we created here in our um Gradle project file if we did that we can sync now and to replace such a Gradle plugin we now need to say lips. plugins instead so not lips. androidx but lips plugins do Android application we don't need to specify the version here since that is contained in the version catalog definition but we need to replace ID with Alias and we can now do the same for our carton version so just go in our version catalog say Okay jet brains cotlin or so paste this here version Catal version reference is cotlin we say okay we actually have a cotlin version here which is 1.9.0 in our case sync this go back to our product file and we say Okay instead of all this after the syn is successful we say we have an alias lips plugins jet brains cuton and same is actually the case here in our app module where we also have these plugins at the very top so here we can also refer to Alias lips plugins Android application and lastly Alias lips plugins jet bra cutland if we now sync this then we completely migrated our empty project from no version cataloges to using version cataloges as I said in newer Android Studio versions this will be the default so the version catalog will already be there with all these standard composed dependencies but I think it's still very important for you to understand how that works so even if you have an older project and you migrate that you really understand where this version catalog file is how how you can create it how you can manually create dependencies in there even though there is some kind of support from end studia at this point but you can see even if we go inside of or activity um then our dependency oh no seems like one of the dependencies isn't resolved or some of them maybe the material one maybe I miscopied something there composed UI material and yes that's actually wrong group needs to be Android X composed material 3 not that one though um but the material one where is it here material paste this sync this and then hopefully our dependencies are resolved yes so everything is recognized just to show you that this really works and isn't just recognized in our grad files but also directly in our main activity awesome below this video you will find a link to more advanced Android premium courses so if you want to become an industry ready Android developer these courses are exactly for you so check these out and other than that thanks so much for watching this video I will see you back in the next one have an amazing rest of your week bye-bye

Channel: Philipp Lackner

Views: 22,977

Keywords:

Id: MWw1jcwPK3Q

Length: 17min 5sec (1025 seconds)

Published: Sun Feb 25 2024