wholesalebad.blogg.se - Android tools build gradle

The module component is the standard group and name, and the version.ref looks up a value from the versions section. Once again this is a simple map, although the definitions for each library are a map.

The libraries section declares the actual libraries themselves. This makes this versions section the single source of truth for all dependency and build tool versions for the entire project. In this example, the compose value is used by a number of separate libraries which we’ll see in a moment.Īs well as libraries, I have also elected to put the Kotlin and Android Build Tools versions in here along with a number of build tools that I use. So defining the version here gives a single instance that needs updating. It can sometimes break things if you only update one of them. I mentioned earlier that sometimes related libraries might share a common version. VersionsĪs its name suggests, the versions section at the top contains the actual library versions. It’s well worth doing this because you’ll get errors when using bundles, otherwise. When you create a toml file, Android Studio may prompt you to install a plugin. It has support for various primitive types along with some simple collections. The format aims to be easy to understand and remember. This is a Tom’s Obvious Minimal Language file. However, we need to enable this feature in order to use it: dependencyResolutionManagement Īndroidx-compose = While they may not be in their final form, they seem to work quite nicely in my testing. Version Catalogs are a new incubating feature in Gradle.

There is one small extra step required to get Version Catalogs to work with the Kotlin DSL, so by going this route, we can cover that when we come to it.

However, I opted to go with the Kotlin DSL for two main reasons: I should mention that the following examples all use Kotlin DSL rather than Groovy DSL for the Gradle config files. The new Gradle feature overcomes this and also offers some other improvements. Changes to buildSrc require re-compilation and this is quite slow. While this works quite nicely, it can slow the build down.

Having a single source of truth makes it much easier to maintain your app dependencies. the navigation-fragment and navigation-ui libraries have a common version. For example, two distinct libraries share the same lifecycle version in the linked example earlier – e.g. It can also simplify things when multiple related dependencies share a common version. It can make it much easier to update a dependency to a new version in a multi-module project. This gives a single source of truth for all dependency versions. Most recently, I have been using a Dependencies.kt Kotlin file in the buildSrc directory. Regular readers of Styling Android may be aware that I like to organise my dependency versioning.