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.

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.

Everyone knows how to display multiple pages using a ViewPager, but since support library version 24.2.0 came out this is no longer the only way. With SnapHelper you can easily add a pager-like feel to your RecyclerView and maybe even make your life easier in the process. This post is about how to setup your RecyclerView along with those page indicators that everyone loves. If you read some of my blog, you might already know what’s coming next:

More about ItemDecorations! :D