Clean Architecture on Android - Example app

In this article, we'll create a super simple Hacker News client with Clean Architecture. We'll also use RxJava, Kotlin, Dagger, and Retrofit to build our app.

You might want to read Clean Architecture on Android where we go through the concepts in Clean Architecture if you haven't already.

Our app, which we'll call HnReader, will consist of a list showing the items currently displayed on the front page of Hacker News. If the user clicks on an item the default browser will display the story. The user should also be able to navigate to the comments and manually refresh the


Clean Architecture on Android

Clean Architecture was introduced by Uncle Bob a few years ago and has grown popular in the Android world. There's nothing revolutionary new about it. But it borrows great ideas from other architectures and put them together in a compelling package.

Uncle Bob used this image to describe his architecture:
Clean Architecture diagram from Uncle Bob
Source 8thlight

The main point of the architecture is that outer layers knows about, and can interact with inner layers but never the other way around. We keep our abstract business logic in the center and the concrete implementations in the outer layers. Our business logic doesn't know, or care


Closer look at scopes in Dagger 2

This is the last part of a write up about Dagger 2 on Android.

All usages of Dagger below refer to Dagger 2


In Dagger 2 we can use the @Singleton scope from JSR 330 or we can define our own scopes. Custom scopes are defined as annotations like this.

public @interface CustomScope {

We use custom scope when we want to reuse dependencies for a custom amount of time. For example, we could


Dagger 2 usage on Android

This is the second part of a write up about Dagger 2 on Android.

All usages of Dagger below refer to Dagger 2

Component lifecycle / Singleton

Dagger, and other DI-frameworks, have the concept of scopes to decide if an instance should be re-used or not. If we don't specify any scope, like in part 1, we'll get a new instance every time we ask for a dependency. That can be suitable for some cases but often we want to reuse