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