Something I’ve only discovered after 10 years of Android development: Setting zero elevation on clickable elements causes them to not being clickable anymore! I haven’t yet investigated whether this is a bug or a feature, but here is a simple workaround (by means of BindingAdapters, but of course you can…

Sifting through the web I stumbled upon a little API called zen which is provided by the guys over at GitHub. The API returns a random (mostly developer focused) piece of wisdom and is accessible via https://api.github.com/zen I thought it might be nice to have such a thing every time…

Oftentimes, when locally building release builds, e.g. to debug issues, you don’t have access to the signing config as you maybe just have it available on your CI — after all you should really try to avoid storing your release keystores on your local development machine. However, Android Studio will…

Today I stumbled about one of these tiny things which — once you uncover them — immensely ease your life. Consider a String with placeholders stored in your strings.xml: Now let's say we want to use that String directly in data binding. Before figuring out the following trick I would fetch the data from the attached ViewModel which would use String.format() to replace the placeholder with e.g. the user name.

Let’s imagine you need to provide a gradient background consisting of arbitrarily many colors to a View. This can’t be done via regular drawable XML as a gradient within a shape can only define three colors: startColor, centerColor, endColor. To reach our goal we will be using data binding. We define an integer array in e.g. arrays.xml and fill it with the desired color resources: Then we define a binding adapter to apply the colors in a gradient to the background of the View:

Oftentimes we find ourselves in the situation of having to pull the values of environment variables into our gradle builds — e.g. to securely provide API keys to use in your code base without having to store them within the repository. Luckily gradle provides us with a very easy way…

Manually testing features based on Observables on a real device during the implementation phase can be tricky. However today I found a really simple trick to do just that. In the following example I’ll be using Kotlin on Android and RxJava, but the concept and RX operators should be applicable…

Today I finally stumbled upon the solution of a really trivial RX problem: Suppose you have an Observable which returns Lists of items. Like Observable<List<String>>. You often receive something like this as responses from web APIs. However chances are you want to operate on the single items, in this case…