Creating bundles in Version Catalog and starting a new project

In the world of AI, I have found it very easy to gloss over the code that is being produced. Very easy to accept things as they are without batting an eye. Even though it might have provided the correct answer, or even a better answer than I could have come up with, it removes the act of actually processing the changes that are being made. To fully understand the problem, the roadblocks, and why certain things just don’t work, I feel like my brain isn’t making those neural connections the way it would while learning something new. Now that code is supposedly solved, the new skill we are developing is the art of debugging: removing the layers of the software onion until the mind reaches a state of clarity.

This newsletter has always been about personal growth. As a developer, a problem solver and a tinkerer. To try things, write them out and move on to the next concept. This is not my way of saying that I am an expert or that people should follow my advice. Probably best if you do your own research. But the art of writing things down to deeply internalize them has always been fun for me. Whether AI changes things or not, I just want to continue walking down this path.

I made an app

Well, not really. I created a new app project as a way of learning new concepts. It’s one of many sample apps that I am creating to get more involved with side projects. What better way to learn than by doing, right? With some apps, I just want to try things out. With others, I want to see how much I can push myself to create and manage real complexity. One complexity I want to avoid for now is the Google Play Store, so to save myself from headaches, I’ll keep my apps in public or private repos on GitHub.

The idea is simple. I want an app that does something with a bit of complex logic, a bit of networking, a bit of database work and some nice UI elements. I have not fully worked out the full feature scope yet, but here’s Endeavor.

I just tagged the 0.1.0 release, which is still pretty bare bones. The app shows a mascot and gives you the ability to add, edit, and delete expeditions.

An expedition is a project you are undertaking. Within your Endeavor, you will take on multiple expeditions. Some are short, some are long. It’s not necessarily a to-do list app, but more of a reflection that you are making progress each day. Even if it’s 1% better each day.

That’s the main gist of the app as of now. Here are some screenshots.

Now comes the learning

This is what excites me the most about this process. Things generally work. Whether it’s a snippet from an online blog or something AI suggests, but why does it work? What would break it? What concepts exist that I am not familiar with and how do I know a good solution from a better one?

I think that is still a trial and error process. With each post, I try to share something that I came across or implemented in my project. So here’s the first one.

Bundles in version catalog

I was updating my version catalog, the piece of the project that defines and centralizes all of the external dependencies that the project needs. I thought about checking out the documentation if anything new has been added recently. The version catalog itself is quite simple. You define the version, libraries and plugins. Then reference them in any build.gradle file throughout the project’s modules.

One thing I explicitly have not used often is bundles. Bundles group together related dependencies. They are separated from BOMs. These dependencies already have their version pre-defined through the version catalog. Sometimes a group of dependencies need to be added for various use cases. For instance, the navigation library in the example below. Defining them in one or multiple build.gradle files without forgetting any particular one can be tricky. With bundles, an alias can be defined to represent a set of dependencies. Then in the build.gradle file, the alias can be used to target that group of dependencies. Quite a nice clean-up mechanism.

An example of the bundle would look like.

libs.versions.toml

[libraries]
androidx-navigation3-runtime = { module = "androidx.navigation3:navigation3-runtime", version.ref = "nav3Core" }
androidx-navigation3-ui = { module = "androidx.navigation3:navigation3-ui", version.ref = "nav3Core" }
androidx-lifecycle-viewmodel-navigation3 = { module = "androidx.lifecycle:lifecycle-viewmodel-navigation3", version.ref = "lifecycleViewmodelNav3" }
[bundles]
androidx-navigation = ["androidx-navigation3-runtime", "androidx-navigation3-ui", "androidx-lifecycle-viewmodel-navigation3"]

build.gradle.kts

implementation(libs.bundles.androidx.navigation)

When to bundle or not to bundle, that is the question. Large bundles will include an excess of dependencies that might not even be required. Small bundles are also quite useless. Keep the dependencies as they are and bundle when it seems necessary, which happens when the project matures and a pattern starts to emerge.

The Endeavor app is quite basic at the moment and it would be overkill to have a bunch of bundles. I’ll keep rolling with the single one and see how these dependencies grow over time.

That’s all for today. In the next one, I’ll go over how to analyze dependencies through one of Gradle’s tasks. I’ll share any progress I make on the project, but as you know, most of the interesting stuff happens between the commits.

Till next time!