Naive question that is more about Gradle than Comp...

# compose

[Travis Griggs]

Naive question that is more about Gradle than Compose maybe... I've experimented around with various different new project templates (in particular the compose ones) and when I look at my module build.gradle file, I see that nearly every line is highlighted yellow. Do people to tend to ignore these? Or update/sync them? Because $compose_version is a variable, it doesn't provide the "Change to <whatever>" action. What's the suggested practice/workflow here? (I'm running Electric Eel)

[Stylianos Gakis]

Which ones are usually yellow? Got some screenshots?
A bunch of those are resolved as soon as you upgrade to gradle 8.0 which is not supported on Electric Eel right now. And for the rest of them, you can let the IDE help you suppress those warnings if you know you don’t care for them.

[Travis Griggs]

Screenshot 2023-02-22 at 1.52.04 PM.png

[Stylianos Gakis]

Oh right that one. But did you see why it’s yellow and what it is suggesting to you?
It can even auto-resolve these for you

[Stylianos Gakis]

And as far as the $compose_version goes, the standard is to simply not use the ext to set this up, but use version catalogs.
The latest Android Studio versions even come with some first iterations on supporting updating the library versions from inside the libs.versions.toml file too

[Travis Griggs]

Thanks for taking the time to reply. I really appreciate it. Hoping to see some fog disperse here eventually.

What I observe is that it can auto resolve the ones that have an explicit version. The question for these then is "is it generally a good idea to do so?". Or is it better to remain conservative? Do I ran the risk of it suggesting a version that my current IDE won't be able to cope with?

I can infer from the prompt that I could go change the compose_version that is defined in the project build.gradle file to the newer version. The questions are similar to above? Is this generally encouraged? What are the risks?

As for

the standard is to simply not use the ext to set this up, but use version catalogs.

Android Studio is new enough to me that I'm not familiar with version catalogs or where/how they are done. By "not use ext", does that mean that it is preferred to just put the version numbers directly in the module build.gradle file?

[Travis Griggs]

(and if so, why does AS not do the "standard" thing when making new projects?)

[Stylianos Gakis]

Yeah, you may bump to a version that the IDE is not compatible with, but that is usually when bumping android gradle plugin + gradle versions, the others shouldn’t be linked with the IDE version. You can be pretty confident when bumping to new non alpha or beta versions, but depending on if you are working on a hobby or real project you may wanna make sure you know what you are bumping too and what implications it may have in your current code base. For a hobby just always bump to latest unless it crashes somehow is what I’d start with.

Okay I wrongly assumed things here, I can try and give you some links. This is what I was referring to. And yeah I did call it “standard”, but to be fair this is fairly new all things considered, and as evident by the fact the android studio doesn’t properly support it on the current latest stable version. Since it seems like you are getting started, I’d suggest you simply define the versions right there inside the dependencies block, and you are writing Kotlin there (or groovy if the file is not build.gradle.kts but it’s build.gradle, still possible), so you can simply make a val to hold the version and use the same variable for all dependencies that use the same version for example. This way you also get proper IDE support.

And NowInAndroid is an example project which uses version catalogs if you wanna check it out, here’s that file, and how it’s used

[Travis Griggs]

I will check that out, thank you very much.

[Colton Idle]

Keeping those templates up to date is a fairly manual task at the moment AFAIK so I'd say yes it's pretty common to see that libraries are out of date because the libraries are updated much faster than the templates.

[Colton Idle]

typically the AS canary templates are better