Dagger 2 articles cycle:

Greetings everyone!

Continue with our Dagger 2 articles cycle. If you haven’t read the first part yet you should do it right now :)

Many thanks to everyone for your reviews and comments.

Here we’re gonna talk custom scopes, components linking via component dependencies and subcomponents. And will touch upon such important subjects as mobile app architecture and how Dagger 2 helps us build cleaner, module-decoupled architecture.

Everyone interested welcome!

Architecture and custom scopes

Let’s start with architecture. Lately this subject is taking a lot of attention, a great number of articles and speeches are devoted to the issue. Subject is undoubtedly important because how we say in Russia: “As you name the boat, so shall it float”. So I strongly advise to read these articles first:

I like the Clean Architecture approach very much. It allows to perform clean vertical and horizontal module composition where each entity does exactly what it should. E.g. Fragment is only responsible for displaying UI and not for making network calls, DB calls, business logic and so on, which could otherwise make the Fragment a nasty big tangled bunch of code. I think it’s familiar to a lot of you.

Consider the following example: there’s an app, which has a few modules, and one of them is a chat module. Chat module contains three screens: single chat screen, group chat screen and settings.

Keeping Clean Architecture in mind we can distinguish three horizontal levels:

Global application level. Here we keep objects needed for the whole application lifecycle, i.e. Global Singletons. Let it be Context (Application context), NetworkUtils (utility class) and IDataRepository (class performing network calls). Chat level. Objects needed for each of three chat screens: IChatInteractor (class implementing particular Chat business cases) and IChatStateController (class responsible for Chat State). Each screen level. Each screen has its own Presenter, resistant to reorientation (meaning its life-cycle is longer than Activity’s one)

Below you can see these life-cycles on the schematic timeline: