agreed, as this way there isn't any visibility of updates for library version. if I'm not wrong, atm, same for Version Catalogue, but I imagine that would be resolved as it's supported by gradle
@@sabbib007madness ig i remember android studio suggesting version updates of all maven dependencies, i never used this method extensively and its also outdated now since version catalogs come baked in ide am pretty sure he just saw he doesnt have a video on that so he made he covers all android related changes 😂
@@sabbib007madness In the last version of the IDE which is Android Studio Giraffe, we now have the "warnings" for new version update in the libs.versions.toml file ;)
This approach saves tons of time once you write it and it works with a version catalog as well! You can reuse the buildSrc module across your projects with a bit of tweaks here an there to fit with the project. Also, it enables flexibility if you have certain requirements. Looking forward to the next part. Keep up the good work Philipp! 🙌🏼
Good video, it's better that managing modules dependencies without "buildSrc"... But gradle version catalogs based on ".toml"-file, convention plugins and composite builds are more convenient and powerful way for the gradle scripts boilerplate reducing.
This really cleans things up in the build.gradle files ! Will gradle highlight those dependencies that have a newer version available (such as core-ktx:1.9.0 in your code)? When I last tried this in one of your courses, I recall that this highlighting no longer worked. How do you easily determine what dependencies are stale?
Why the project level gradle specified plugins using plugins { id .. version .. apply false } syntax, and buildSrc gradle file uses dependencies { .. } syntax? Can you clarify that, please?
Great stuff as usual. got a question though, looks like this method won't get automatic version upgrade tips, that is, gradle won´t tell you that a newer version is available. Will you cover that in your next video?
Man I thought it was gonna be a video about DI in multi-module app xD. Anyway it would be better to use version catalogs. The new Android Studio also supports it fully now.
Cool Video😁👍. I just have one question: Why didn't you write the room()-Function as an Extension of DependencyHandlerScope, because then you would not need those extra Helper Functions. I already tried this out some time ago and it worked perfectly fine. Or is this considered a bad practice?
How the DependencyHandler extension function would be for a dependency like testImplementation("whatever") { exclude(group = "whateverGroup", module = "whateverModule") } ?
Found an answer: fun DependencyHandler.testImplementation( depName: String, dependencyConfiguration: ExternalModuleDependency.() -> Unit = {} ) { add(“testImplementation”, depName, dependencyConfiguration) }
Why would anyone want to go through all of these when we could manage the dependency for all the modules using the version catalog, which let's me manage all the dependency versions in one place.
IMO i think version catalogs + convention plugins is the way forward since it supports natively in gradle
agreed, as this way there isn't any visibility of updates for library version. if I'm not wrong, atm, same for Version Catalogue, but I imagine that would be resolved as it's supported by gradle
Tutorial is coming soon as well👍🏼
@@sabbib007madness ig i remember android studio suggesting version updates of all maven dependencies, i never used this method extensively and its also outdated now since version catalogs come baked in ide am pretty sure he just saw he doesnt have a video on that so he made he covers all android related changes 😂
@@sabbib007madnessit shows possible updates
@@sabbib007madness In the last version of the IDE which is Android Studio Giraffe, we now have the "warnings" for new version update in the libs.versions.toml file ;)
Finally a multi module series ❤️
That was great. I only got it right the fifth time, but now I fully understand how it works. Thank you very much!
why not Version Catalog?
Wow, 3 minutes in and I have already grasped plenty of stuff I was struggling with on some Opensource repo.
This approach saves tons of time once you write it and it works with a version catalog as well! You can reuse the buildSrc module across your projects with a bit of tweaks here an there to fit with the project. Also, it enables flexibility if you have certain requirements. Looking forward to the next part. Keep up the good work Philipp! 🙌🏼
Thank you so much @Philipp for all great videos.
I highly recommend using bundle in version catalogs
Good video, it's better that managing modules dependencies without "buildSrc"... But gradle version catalogs based on ".toml"-file, convention plugins and composite builds are more convenient and powerful way for the gradle scripts boilerplate reducing.
I'll make a video about version catalogs soon :)
Ooh back to back!
Well done
This really cleans things up in the build.gradle files ! Will gradle highlight those dependencies that have a newer version available (such as core-ktx:1.9.0 in your code)? When I last tried this in one of your courses, I recall that this highlighting no longer worked. How do you easily determine what dependencies are stale?
Love your vids. Would love to see a video on fingerprint authentication
Superb! Eagerly waiting for the next video.
As far as I know, in Preview versions of Android Studio a TOML version catalog is the default option for dependency management
Perfect video I've been found !! Thanks !
Phillip... You re pure gold!
Why the project level gradle specified plugins using plugins { id .. version .. apply false } syntax, and buildSrc gradle file uses dependencies { .. } syntax? Can you clarify that, please?
What is the best way, when the proyect is multi repo ? This inplementation is very hard in these scenary with multiple developer team
super helpfull video Philipp , thanks a lot 💗
How can we create separate module that only have apis call or repository
What is best practices
use bundles in gradle catalog, gradle is already slow enough, no need to add extra overhead to your builds with buildSrc and the likes
gradle recommends to use composite builds over buildSrc
Great stuff as usual. got a question though, looks like this method won't get automatic version upgrade tips, that is, gradle won´t tell you that a newer version is available. Will you cover that in your next video?
I believe you can achieve same thing with Versions Catalog bundles ¿right?
Hello, Philip, I would like to know from you: is it worth learning xml or is it worth going straight to compose?
for legacy projects you may need it similarly as you need java
is there a playlist with all the videos around multi module?
version catalogs seem more intuitive for managing dependencies for all modules. great usecase for using the gradle buildSrc
Man I thought it was gonna be a video about DI in multi-module app xD. Anyway it would be better to use version catalogs. The new Android Studio also supports it fully now.
@Philipp I have a request. Can you please add sequence to the Playlist? I don't know where to start and where to go from there😅😅😅
That's great! Thank you for your work!Great!
on point, thats what i need right now
Cool Video😁👍. I just have one question: Why didn't you write the room()-Function as an Extension of DependencyHandlerScope, because then you would not need those extra Helper Functions. I already tried this out some time ago and it worked perfectly fine. Or is this considered a bad practice?
I still would rather to use version catalogs.
You are so dependent on dependencies, try to get rid of it. 😅
@@akashkumardas6521 Already dependent. No way out of it :))))
How the DependencyHandler extension function would be for a dependency like testImplementation("whatever") { exclude(group = "whateverGroup", module = "whateverModule") } ?
Found an answer:
fun DependencyHandler.testImplementation(
depName: String,
dependencyConfiguration: ExternalModuleDependency.() -> Unit = {}
) {
add(“testImplementation”, depName, dependencyConfiguration)
}
I also think you should remove "THIS Is How You Need to Do It" and move into catalogs and group dependencies in bundles section
this is the best thanks !
Hilt is not working dude. Help me out here
Kotlin 1.9.0 and Dagger Hilt 2.48
It changes a lot and I don't know if it's possible because the kapt was removed
This is not the best solution for dependency management, a change in buildSrc will causes the whole project to become out-of-date.
Thank you!
i'm just curious can i apply in java android project?
I think I'll go with the grade versions catalogs
I enjoy your videos sir 😎 thank you
You need to learn how to use a TOML file with version catalog.
Nice !
I guess version catalog provide same feature as buildSrc..
sir Please make a video on Smsmanager in android Api level 33
Great content 🔥
fantastic
Waiting for next video
Why would anyone want to go through all of these when we could manage the dependency for all the modules using the version catalog, which let's me manage all the dependency versions in one place.
i want to learn Flutter/Dart, but because of this guy im with kotlin 😅
Cool 🚀
GOAT
The title should be "Gradle Dependency Management...."
Right! Half of the video I was thinking "that's a long introduction into DI" until I realized he named it ambiguously
goat
Can we have some videos on Android hardware please
Coming
@@PhilippLackner thank you so much💜
n🧊 one