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 ;)
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?
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?
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.
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'm just curious can i apply in java android project?
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) }
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! 🙌🏼
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 ;)
Ooh back to back!
Well done
why not Version Catalog?
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 :)
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 :))))
I believe you can achieve same thing with Versions Catalog bundles ¿right?
This is not the best solution for dependency management, a change in buildSrc will causes the whole project to become out-of-date.
Finally a multi module series ❤️
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?
I also think you should remove "THIS Is How You Need to Do It" and move into catalogs and group dependencies in bundles section
You need to learn how to use a TOML file with version catalog.
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?
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.
i want to learn Flutter/Dart, but because of this guy im with kotlin 😅
What is the best way, when the proyect is multi repo ? This inplementation is very hard in these scenary with multiple developer team
gradle recommends to use composite builds over buildSrc
Wow, 3 minutes in and I have already grasped plenty of stuff I was struggling with on some Opensource repo.
That was great. I only got it right the fifth time, but now I fully understand how it works. Thank you very much!
I guess version catalog provide same feature as buildSrc..
How can we create separate module that only have apis call or repository
What is best practices
Love your vids. Would love to see a video on fingerprint authentication
super helpfull video Philipp , thanks a lot 💗
Thank you so much @Philipp for all great videos.
I highly recommend using bundle in version catalogs
Hilt is not working dude. Help me out here
@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😅😅😅
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
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?
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
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.
As far as I know, in Preview versions of Android Studio a TOML version catalog is the default option for dependency management
use bundles in gradle catalog, gradle is already slow enough, no need to add extra overhead to your builds with buildSrc and the likes
version catalogs seem more intuitive for managing dependencies for all modules. great usecase for using the gradle 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'm just curious can i apply in java android project?
I think I'll go with the grade versions catalogs
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)
}
is there a playlist with all the videos around multi module?
fantastic
sir Please make a video on Smsmanager in android Api level 33
Superb! Eagerly waiting for the next video.
That's great! Thank you for your work!Great!
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
I enjoy your videos sir 😎 thank you
Waiting for next video
this is the best thanks !
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! 🙌🏼
Nice !
on point, thats what i need right now
Phillip... You re pure gold!
GOAT
Cool 🚀
Thank you!
goat
Great content 🔥
Can we have some videos on Android hardware please
Coming
@@PhilippLackner thank you so much💜