You drop material3 into your project and start coding away, but say you want to change some style down the line: now you gotta do a full usage search, figure out if that specific usage is part of your change, and change it. In every single place.

Now, “Of course”, you’ll say, “this is Compose, so we should create our own composable and we will use that instead.” and you’d be right; this is the approach we will be discussing in this post. But there is one extra step that we can take to make this intent not only clear, but also enforce it as the default: modules.

Android Theming works great once you really get into it, but one of the biggest limitations is that you can’t modify those themes at runtime. You can override some values, but you always need to know those colors at compile time and create more themes or theme overlays.
You can achieve dynamically colored themes with some libraries that will either use their own View implementations or some amount of workarounds to get it working good enough but not completely.

Android 11 added the option to include your own Resource Loaders and with that we finally have a way to dynamically alter our apps themes dynamically.
We can tell Android to load a separate file which will override any existing resources, so we could for example change our colorPrimary and marvel at how all buttons, colors, etc will just work as if we had switched the color at compile time.

I’d like to take a look at how we can improve our most basic layouts—both for maintainability and for performance. Let’s get right to it and take a look at this very basic example of a list element for a simple label that should look familiar to both beginners and experts. While this is a very minimal example it’s a great place to touch on a few topics relevant to us all.

Show a splash screen while the content is loading without further delaying the app startup time. Maybe even throw in some small animations and you’ll have a great first impression.

Binding Room to Dagger does not involve any boilerplate at all if we bind it as a dependency. Like Dagger, Room uses an annotation processor to generate the implementation of our database and DAOs. This implementation will create the DAOs the first time they are accessed, then cache the objects for future calls, limiting them to a single instance. Sound familiar? It should. This is very similar to what a Dagger component does with scoped objects—we can use this and bind the database as a dependency directly to our component. No need for any modules.

Where to do you move your map for a user that did not (yet) grant you the location permission? Can we guess the user’s nationality or dial code, rather than make them go through a list of all 200 countries? Neither is especially bad when left unhandled, but this is also a great opportunity to improve user experience and make the app feel quicker and more responsive.

We can use TelephonyManager to fetch the country code of the user’s SIM card, or even read the country (of the network) the user is currently in. While this is very basic information, there is a good chance that it is available—without the need for any permissions or network calls. While internationalization efforts in apps often include translations of the resources and layout adjustments for different content lengths or directions, here I’d like to explore some of the possibilities that this information opens up.

For the love of logic, stop reading some Dagger tutorial, copy-pasting some code, and then expecting magic to happen. Dagger does not magically set your variables and remove nulls from your code. You have to understand how Dagger works before using it, or you will end up creating more work than you tried saving.

This said, Dagger is not as complicated as it may seem. It follows a few basic rules, so by knowing those rules, you know Dagger.

There are a lot of different approaches on how to add a splash screen to your app. Whatever your approach, it will be fine unless you use a dedicated SplashActivity. Using an activity as a splash screen is just wrong, and it will mess up your navigation sooner or later. After all, a splash screen should be shown while the app is loading and it should not depend on where a user comes from or what started the app. In the following, I want to show an easy setup that needs only minimal changes to your existing code base.