A lot of guides cover the basic setup of Dagger and how to use it in your projects, but how would you provide different implementations of an interface with Dagger? In the following I want to look at a real world example: A Car, that either could take a PetrolEngine or an ElectricEngine!

Now that we have a goal in mind all we need to figure out is how to do this with Dagger.

Keeping state on Android is always a little bit tricky and confusing. You either have to use some sort of singleton, store data in your Application object, or make use of the good old onSaveInstanceState. There is also always the option to use a service.

Saving instance state can’t persist running operations like loading data. Using singletons or the application object to store data makes all of this possible, but global state is also something you should try to avoid unless really necessary. I will not go into detail about whether or not and how to use services, since this is a whole topic by itself.

I tend to use RxJava with Retrofit and a while ago I was wondering whether there was another way to keep state over configuration changes. Loaders came to my mind, which I do believe are well underused lately. And Loaders are supposed to handle long running tasks and keeping data, right?

While I personally wish there was OAuth everywhere, most apps still require a password somewhere. So while building this sign up page you might just want to give your user a hint about the strength of their chosen password, whether you validate it or not.

Most apps have to talk with servers in some ways and testing is not always easy. There are multiple steps involved to set up the test data, and sometimes a specific request can only be triggered once. Whatever the reason, often there is some work involved to test even the most basic things. So why not just cut out the server and provide your own data?

You might even get something like a demo or offline mode in the process.

Flavors enable you to have multiple similar versions of your app within a single code base, like different colors, or the common example of a paid and a free version of the same app. They greatly increase maintainability, as well as publishing updates to multiple apps gets significantly easier. But while having different settings for every flavor is simple enough, things start to get really tricky if you introduce flavor dimensions and find yourself dependent on combinations of different flavors and build types.

Let’s assume I have a news and a blog app. Both could be some sort of RSS reader and they share the same code base. I also have a development and a production environment, because I don’t always test my code, but when I do, I test it in development! :)

The basic setup is simple and I define my flavor dimensions as well as my flavors. Because I actually have two different apps, each one has it’s own unique applicationId.

flavorDimensions "app", "environment"
productFlavors {
  news {
    dimension "app"
    applicationId "com.example.news"
  }
  blog {
    dimension "app"
    applicationId "com.example.blog"
  }
  development {
    dimension "environment"
  }
  production {
    dimension "environment"
  }
}

Now that things are set up I want to go ahead and add the URLs to my server and this is where things get complicated.

Since I have two apps each app has its own URLs, one for development, and one for production.

More often than not you will find yourself in a position where you need some…custom behavior. Whether you want a view to keep a 16:9 aspect ratio, or want a view to scroll—and still fill the screen.

Don’t be afraid to create and use your own layouts. Not only will they have great reusability, they will save you time and ease your life. If you start repeating the same pattern in your layout files…maybe you should just create a custom View. Your layout will stay clean and simple while you have better maintainability when something changes.

Most important of all: If you like using ViewTreeObserver to adjust your layouts drop everything right now. This post is for you.

If you feel like generating your own source code there is little information available on how to start or where to begin. In this post I want to offer some introduction into Java annotation processors, how to generate source code, and—most importantly—how to test it.

For the sake of this guide I just want to stub out a simple interface.

interface Teapot {
    void boilWater();
    boolean isBoiling();
}

Yea…this should not be too hard…and who does not like tea?

My two cents on how to deal with wrapped json objects by using Retrofit converters

I’m sure everyone has had the joy of dealing with wrapped objects in json. The best part of them is that you get to check for errors 3 times: IOException, isSuccessful, and the response’s custom result code, if you were to use the default Call<> object provided by Retrofit 2.