So for 99% of the apps that we write, this just adds more files to keep track of, another format to remember, and more layers we have to sift through to find build bugs. Thank you, my job wasn't hard enough already.
You can also have a bundles section, where you set up way add multiple dependencies will a single line. It's very handy for things you always use together. Like all the compose dependencies.
Ah! This is great. Been working on the same big project for a while, so when i created a new project in Jellyfish for a small app this morning and went to add dependencies, the first reaction seeing the libs system was "WTF!?". Was tempted to revert back, but the OCD had won 😂 After it had taken me the best part of the morning to figure out the version catalog system on my own and add all my drpendencies manually, decided to migrate my big project... for which this video was, as usual, A GODSEND! Seriously, you're a lifesaver ❤
This is nice and definitely makes it easier to manage dependencies for large projects. When I look at build scripts that use version catalogs, I just find it a bit hard to build a mental model of dependencies. Before version catalogs, it was easier on the eyes to figure out what "groups" we are using in our application.
In addition to your content I'm also making use of "bundles" there. For example all the compose dependencies could be bundle together and instead of 4 implementation you only got 1 left in your gradle file. But that's of course an indivuall preference 🙂
Haven't found much use for that yet, since in a single module app, you'll have to add them all to your Gradle file anyways and in a multi-module project, I got used to work with convention plugins which also didn't make me feel like that was necessary. Still thanks for adding though!
@@PhilippLackner I can't believe it. Bundles make my life soo much easier, even if I'm also using Convention Plugins. Just wrap all the multiple dependencies for one library such as Koin or Retrofit and then just call your bundle in one line. It's soo good!!
Another nice feature is that you can create "bundles". So say that you have related dependencies like compose for instance, then you can create a bundle of these. You can then in you app gradle file just refer to "implementation(libs.bundles.compose)" for instance.
Now I'm using Android Studio Koala and it already appled the version catalogs for the library dependencies. Thanks for your information 6 months ago :)
Great video, Philipp! Is it possible to use the versions catalog and group dependencies like you did in the video "Perfect Dependency Management"? I mean, call room() and add all the dependendencies related to it.
this was helpful i was watching an old tutorial on app development that was released on 2021 and i was confused as to why my dependency lines were red while his was fine XD
It would be nice to mention about bundle in version catalog. And it would be pretty convenient if version catalog has opportunity to define groups like versions )))
Thanks Philipp for your great work ! I have seen gradle team has inculded this video link in their latest newsletter published for march, 2024. I have a question related to it though, appreciate if you can point me to something. With version catalog added to my project, I am not able to generate a gradle.lock file, and it always fails to identify the dependencies. There are multiple open bugs pending with gradle for the same and gradle team not showing the appetite to fix those as well.
Invalid catalog definition: - Problem: In version catalog libs, you can only call the 'from' method a single time. (i called just one time, what is wrong?) dependencyResolutionManagement { versionCatalogs { create("libs") { from(files("gradle/libs.versions.toml")) } } }
Something is not clear for me. For example, if we use timber library we can use : timber="5.0.1" timber = { group = "com.jakewharton.timber", name="timber",version.ref="timber"} timber = { module = "com.jakewharton.timber:timber",version.ref="timber"} ? It is the same thing if we use group or module? I don't understand the difference between them.
Hi @PhilippLackner, I am busy doing your Multi-Module Architecture paid course and I just finished the Module Setup video. Am I correct in assuming that the Version Catalogue can completely replace the buildSrc method of managing dependencies? And will you update your course with the Version Catalogue method?
Great Video Philipp. Rant:- IDE support for this is worse, why don't Android Studio, just create a simple GUI interface, which makes it easier. Upgrading is mess, unused libraries in version catalogue is a mess. I don't like the new way of doing things, it's like we are intentionally making it difficult to import libraries, but as long as we get paid, eh.
i am learning android using your old projects but i am facing issue in your news app. I am stuck at a point from 3 days but i don't get any solution.i am using new version of android that is hedgehog. Please tell me what should i do?
Came here to solve the same problem at 12:56 (material reference error) and you cut how you solved it :/ update: New projects don't include old material dependency, only material3
Updated to the nosebleed version of android studio, ksp, jdk 21 etc. Dependency management is nice. They have done something new with resources as well. factoring and refactoring and rere.... I swear building the framework for an application takes longer than writing the logic. For MVVM I should just be able to configure the entities and click generate. stub the business logic and save a bunch of time. by the time you write 3 mvvm applications it's going to get pretty dull
Thank you for great video! :) I'm trying to migrate from buildSrc Deps object in KMM to that catalogs ;) P.S.: Don't forget to update KMM Translator ;) P.S.S.: The name of lib in 21 line should be androidx-compose-ui-test-manifest ;)
I have worked in Javascript land for over 3 years of my life and felt like nothing is better. But after working with Gradle for a year, I have realized why it is superior than NPM. I am not saying it is the best, but it is definitely better than NPM.
Hi Philip I am not able to add the Hilt dependency using this approach, as it gives this error: Duplicate class org.intellij.lang.annotations.Identifier found in modules annotations-12.0.jar -> annotations-12.0 (com.intellij:annotations:12.0) and annotations-23.0.0.jar -> annotations-23.0.0 (org.jetbrains:annotations:23.0.0) I have this in toml [versions] hiltCompiler = "1.2.0" [libraries] androidx-hilt-compiler = { group = "androidx.hilt", name = "hilt-compiler", version.ref = "hiltCompiler" } in build.gradle(apps) implementation(libs.androidx.hilt.compiler) see if if you could help here
This is so bad, as if it wasn't complicated enough already they decided to add a new language file 😢, why can't we take an idea out of flutters playbook? Their pubspec file makes all of this so easy
This feature has been out there for a while and is actually one of the best ways to handle dependancies in Gradle projects. All your dependencies for your modules are centralized, you get autocomplete for plugins and dependencies in your Gradle scripts, you can use bundles to make your dependencies sections even smaller ... I think that it should be the standard for that propose, give it a try and you'll see how good it is 😉
"Finally, developers can now use one language, Kotlin, for the logic, UI and also build config" "Unacceptable, let's bring in a completely new language without logic, code completion or even type safety. We'll build an extra tool to handle that." "Emmm, ok. We could then group the libraries together. For example with a dot like in the rest of the code?" "Boooooring, let's use dash on one side and dot on the other. So that they can't do a litelar search. Wink wink"
So for 99% of the apps that we write, this just adds more files to keep track of, another format to remember, and more layers we have to sift through to find build bugs. Thank you, my job wasn't hard enough already.
You can also have a bundles section, where you set up way add multiple dependencies will a single line. It's very handy for things you always use together. Like all the compose dependencies.
You're the best, Native developer!!!
True
yes, it's true!
Ah! This is great. Been working on the same big project for a while, so when i created a new project in Jellyfish for a small app this morning and went to add dependencies, the first reaction seeing the libs system was "WTF!?". Was tempted to revert back, but the OCD had won 😂
After it had taken me the best part of the morning to figure out the version catalog system on my own and add all my drpendencies manually, decided to migrate my big project... for which this video was, as usual, A GODSEND!
Seriously, you're a lifesaver ❤
Will you make a video combining versionCatalog with buildSrc ?
I hope to see a new video about buildSrc module that supports this toml file
This is nice and definitely makes it easier to manage dependencies for large projects. When I look at build scripts that use version catalogs, I just find it a bit hard to build a mental model of dependencies. Before version catalogs, it was easier on the eyes to figure out what "groups" we are using in our application.
In addition to your content I'm also making use of "bundles" there. For example all the compose dependencies could be bundle together and instead of 4 implementation you only got 1 left in your gradle file. But that's of course an indivuall preference 🙂
Haven't found much use for that yet, since in a single module app, you'll have to add them all to your Gradle file anyways and in a multi-module project, I got used to work with convention plugins which also didn't make me feel like that was necessary. Still thanks for adding though!
Bundles are very nice approach, we are also using to group dependencies and use them as single line in gradle file.
@@PhilippLackner I can't believe it. Bundles make my life soo much easier, even if I'm also using Convention Plugins. Just wrap all the multiple dependencies for one library such as Koin or Retrofit and then just call your bundle in one line. It's soo good!!
Another nice feature is that you can create "bundles". So say that you have related dependencies like compose for instance, then you can create a bundle of these. You can then in you app gradle file just refer to "implementation(libs.bundles.compose)" for instance.
Nice to see this is being done. Sad that I did this all manually and now I have to unwind it. :)
Now I'm using Android Studio Koala and it already appled the version catalogs for the library dependencies. Thanks for your information 6 months ago :)
thanks philips, this is great 🤙
Great video, Philipp!
Is it possible to use the versions catalog and group dependencies like you did in the video "Perfect Dependency Management"? I mean, call room() and add all the dependendencies related to it.
of course，You can use a bundle
thanks for this video. this tutorial helped me a lot upgrading my gradle from to old and I now understand toml very well. thanks again bro
this was helpful i was watching an old tutorial on app development that was released on 2021 and i was confused as to why my dependency lines were red while his was fine XD
It would be nice to mention about bundle in version catalog. And it would be pretty convenient if version catalog has opportunity to define groups like versions )))
This is awesome, man!
will you update multi-module course with version catalogs instead buildSrc ??
How about Version Catalogue vs Gradle Kotlin DSL comparation?
Thanks Philipp for your great work ! I have seen gradle team has inculded this video link in their latest newsletter published for march, 2024. I have a question related to it though, appreciate if you can point me to something. With version catalog added to my project, I am not able to generate a gradle.lock file, and it always fails to identify the dependencies. There are multiple open bugs pending with gradle for the same and gradle team not showing the appetite to fix those as well.
Great video to know about the version catalog ❤
your videos are very top! Thank you so much for sharing your knowledge.
😍🤩🥳❤🙏
Invalid catalog definition: - Problem: In version catalog libs, you can only call the 'from' method a single time. (i called just one time, what is wrong?)
dependencyResolutionManagement {
versionCatalogs {
create("libs") {
from(files("gradle/libs.versions.toml"))
}
}
}
this is very helpful for me . for this i can use string dependencies to library dependencies.
thank you .
I tried recreating your room beginner project with this version catalog android studio and I keep getting an error with classes conflicts
Can you also do this with hilt dependency injection? I cant make ik work.
Something is not clear for me. For example, if we use timber library we can use :
timber="5.0.1"
timber = { group = "com.jakewharton.timber", name="timber",version.ref="timber"}
timber = { module = "com.jakewharton.timber:timber",version.ref="timber"}
? It is the same thing if we use group or module? I don't understand the difference between them.
I'm using version catalog for a while but I didn't know that was possible uses the shortcuts to move build.gralde depencies into toml file.
how can we add classpaths and how to find the proper versions of the plugin
Thank so much, understood thanks
would you say this is more ideal than using a buildSrc in a multi-module app?
Yes
thanks @@PhilippLackner would love to see a video comparing buildSrc vs Version Catalogs with some pros and cons of each
Hi @PhilippLackner, I am busy doing your Multi-Module Architecture paid course and I just finished the Module Setup video. Am I correct in assuming that the Version Catalogue can completely replace the buildSrc method of managing dependencies? And will you update your course with the Version Catalogue method?
@@MarkOverton-fn4gm yes you are
Thanks for this Philipp
Would be great if you could make a video on automating Gradle dependency updates through Github Actions.
Great Video Philipp.
Rant:-
IDE support for this is worse, why don't Android Studio, just create a simple GUI interface, which makes it easier.
Upgrading is mess, unused libraries in version catalogue is a mess.
I don't like the new way of doing things, it's like we are intentionally making it difficult to import libraries, but as long as we get paid, eh.
how do we defind a dependency to a module when using version catalog?
Hey your location tracking app doesnt seem to auto update anymore, do you know why?
i am learning android using your old projects but i am facing issue in your news app. I am stuck at a point from 3 days but i don't get any solution.i am using new version of android that is hedgehog. Please tell me what should i do?
Came here to solve the same problem at 12:56 (material reference error) and you cut how you solved it :/
update: New projects don't include old material dependency, only material3
King of Android.
Thank you philipp :)
Very cool. BTW. Should androidx-compose-tooling-ui-manifest be named androidx-copmose-ui-test-manifest?
I prefer your approach to using kotlin build src folder with variables and so forth. Its easier to manage and clean. Or am i missing something?
You don't get the hint that there are newer versions if you use that approach
Updated to the nosebleed version of android studio, ksp, jdk 21 etc. Dependency management is nice. They have done something new with resources as well. factoring and refactoring and rere.... I swear building the framework for an application takes longer than writing the logic. For MVVM I should just be able to configure the entities and click generate. stub the business logic and save a bunch of time. by the time you write 3 mvvm applications it's going to get pretty dull
Thank you for great video! :)
I'm trying to migrate from buildSrc Deps object in KMM to that catalogs ;)
P.S.: Don't forget to update KMM Translator ;)
P.S.S.: The name of lib in 21 line should be androidx-compose-ui-test-manifest ;)
I'm been using this for 2 years now. It's a big improvement but I still don't like the TOML file format.
What is the advantage of using this over the regular build.gradle?
One source of dependencies for multi module projects
@@PhilippLackner makes sense. did not think in that way. Good to know. Thanks for the video
Do they also support notices about new versions of the dependencies?
Yes, there will be a yellow squiggly in the version catalog when there is a new version, just like in the build.gradle file.
@@robchr Great 🤩 This was always a problem some years ago back when I tried out own version catalogs by gradle ext.
Hi, I'm new to android developmet, is it better to get started with view xml or jetpack compose?
Compose all the way
compose , don't waste time learning xml !!
Hi Philip Kindly Make an App Demo for a Live Streaming app For HLS or TH-cam Using Jetpack Compose and Kotlin.
Eres la cabra Phillipp gracias!
How to add kotlin-kapt
Can we have more of your opinions? If you dont want to put then on the main channel i understand
Opinions about what specifically? 😄
Version Catalogs are the default in Android Studio Jellyfish | 2023.3.1 Canary 11
We have the same + build conventions
How to add maven with pom , instead of using Gradle in android studio koala version
Thank you BRO
Why not they introduce yaml file like Flutter
Bundles is missing here.
They are just increasing complexity, adding dependency is much easier in other frameworks, this is the thing which i don't like about android.
how to create hilt plugin with version catalog? I didn't find instruction at docs.
I was find it for dagger, not for hilt
Wouldn't using Version Catalogs be more relevant for Multi-Module Apps?
Yes, but it also becomes the standard for single module apps
Aha, now I see, the vision
I’m waiting for the day when they’ll create a dependency manager like Rust’s Cargo or JavaScript’s npm.
I have worked in Javascript land for over 3 years of my life and felt like nothing is better. But after working with Gradle for a year, I have realized why it is superior than NPM. I am not saying it is the best, but it is definitely better than NPM.
Hi Philip
I am not able to add the Hilt dependency using this approach, as it gives this error:
Duplicate class org.intellij.lang.annotations.Identifier found in modules annotations-12.0.jar -> annotations-12.0 (com.intellij:annotations:12.0) and annotations-23.0.0.jar -> annotations-23.0.0 (org.jetbrains:annotations:23.0.0)
I have this in toml
[versions]
hiltCompiler = "1.2.0"
[libraries]
androidx-hilt-compiler = { group = "androidx.hilt", name = "hilt-compiler", version.ref = "hiltCompiler" }
in build.gradle(apps)
implementation(libs.androidx.hilt.compiler)
see if if you could help here
This is so bad, as if it wasn't complicated enough already they decided to add a new language file 😢, why can't we take an idea out of flutters playbook? Their pubspec file makes all of this so easy
I wrote this early in the video after seeing all the generated info this is so stupid
This feature has been out there for a while and is actually one of the best ways to handle dependancies in Gradle projects. All your dependencies for your modules are centralized, you get autocomplete for plugins and dependencies in your Gradle scripts, you can use bundles to make your dependencies sections even smaller ... I think that it should be the standard for that propose, give it a try and you'll see how good it is 😉
@@tygourm you're right I should but did we really need a new file type to learn
@@tygourm also I didn't realise how long this has been around I thought it was new
@@tygourm I hear you when you say it's the best way because the old way sucked I'm asking if this is a good
So the only thing this does is adding an extra file to your project. I don't like that approach.
Can someone explain why use this!? It look like few steps more then before, and I don't see any extra benefits from doing stuff this way
"Finally, developers can now use one language, Kotlin, for the logic, UI and also build config"
"Unacceptable, let's bring in a completely new language without logic, code completion or even type safety. We'll build an extra tool to handle that."
"Emmm, ok. We could then group the libraries together. For example with a dot like in the rest of the code?"
"Boooooring, let's use dash on one side and dot on the other. So that they can't do a litelar search. Wink wink"
Hello world !
My college faculty be like this could be done by creating val for version 😂
Already know sir but thanks for the video ❤
This feels so unnecessarily over-engineered
You don't have to do this in a monolithic project. This is the best and recommended way in a multi-module project.
👍