How to build Android Architecture? - Quick Guide

Reason for Android Architecture Component

Long story short, for a long period of time there were no official guidelines how to create Android applications. Newcomers into Android development often stumble with a lot of different approaches (architecture patterns) of how to create apps in the “correct” way. Actually, there is no such way. But it`s good way to start and do it right from the very beginning.

Get the job done

There are a lot of posts and articles about Android Architecture Components. So, to be short let's check this diagram which should summarize the whole usage of the components.


All this explanations and flowcharts are good, but let's try to understand it with simple ToDo app. Basic user flow within the app may be represented by this flowchart:


First of all, let's create class TaskViewModel with methods which represent user actions on the view:


At first glance, such implementation could be unusual for you but it makes sense. Let's dig into the code and you will see big possibilities.

The keys to such implementation are MutableLiveData and Transformations class. MutableLiveData allows us to set the value from the outside as general LiveData allows changes only within the class. Transformations react to changes in LiveData object and call function from the second argument.

There we can:

  • Save data
  • Request new data
  • Show progress

MediatorLiveData observers data changes of the other LiveData. The ideal candidate for loading notifying. And we actually do all these things. At this point, you may notice that our ViewModel doesn’t work with data source directly so we can use any data source (network, cache, local). To use this ViewModel in our activity or fragment and use all the power of internal configuration change handling we should get it with the following code:


Here "this" can be activity or fragment and based on it scope of ViewModel will be defined. Such approach also allows us to create separate Fragments and interact with each other with activity scoped ViewModel. So far, so good. If you create your ViewModel in such may your app will crash. Sweet. The reason for that is in the way ViewModels are provided. Internally it uses default (empty) constructor which we don’t have. We can remove Repository but in such way, we will break three important things:

  • Testability
  • No data loading directly in ViewModel
  • Single responsibility principle and Dependency inversion principle (S and D from SOLID)

To make it work we may use:

We allowed to use custom factory for our ViewModels:
public class ViewModelFactory extends


Here we can create repositories and other dependencies directly or use dependency injection. Now, everything works and everyone is happy. On your view, we can add LiveData observers add live a happy life.


In the repository, you may use local storage, send API calls or do whenever you want to store the data. For sake of the example, I use SharedPrefences and AsyncTasks.



Android Architecture Components are version 1.0 now which give us a nice background to create better applications and become better developers. Anyway, it is your decision whether using it or not in your app. Maybe MVP, MVVM, VIPER or other approach is better for you.

Github sample:

Techmagic - Good&Co case study