Navigating MVVM with Dagger 2 , Coroutines and Android Architecture Components-Covid19 app sample
For the record , this is my first attempt writing an article here on Medium , although i have been a fan of the website and the android community here since a while now .
Also to be honest , i have a lot of free time now since the outbreak of the Coronavirus , so i thought i’d share with you the app that i wrote and talk about some of the details of it .
Ok let’s give it a shot , in this article we will talk about implementing MVVM in an android application with Dagger 2 ,Coroutines and AAC(Android Architecture Components) …
when it comes to writing a new android application, the first question that comes to mind would usually be what’s the architecture of the project will look like (the presentation layer in a clean architecture project).
I would say that Android development is in a mature state and choosing an application architecture comes to basically choosing between MVVM , MVP and MVI.
Recommended app architecture
I will leave MVI(Model-View-Intent) to another separate article maybe and start with MVP(Model-View-Presenter) which is a well establish architecture and has some strong valid points that are worth considering such as the separation of responsibilities between components which can allow us to test the presenter logic and also allow us to modify and maintain the app easily .
On the other hand we have MVVM (Model-View-ViewModel), the recommended app architecture from Google and what i prefer to work with to be honest .
MVVM brings some interesting functionality to the table that are supported by google and makes the developers life less painful compared to MVP such as :
- No more Callbacks , Observers instead with Livedata with a true separation of concerns .
- creating less files to work with since we don’t need interfaces to transfer data between the different components ,
- In MVP the presenter is tied to a single view and in MVVM we can have shared view models to work with multiple fragments (which we will talk about soon)
As you already noticed in the diagram below ,the architecture proposed by Google uses ViewModels with Livedata and the Repository pattern .
ViewModels
The ViewModel class is designed to hold and manage UI-related data in a life-cycle conscious way. This allows data to survive configuration changes such as screen rotations
As we all know , the android activity has a rather complicated and messy behaviors to deal with ,if you don’t know what you are getting into in the first place, and has many callbacks and various states (like Running, Stopped, Paused and Killed) that needs to be dealt with .
Back to the ViewModel , as we said earlier ,being life cycle aware is a huge plus for handling our data safely , as we see in the figure below , the ViewModel survives all the activity states and configuration changes .
As you can notice in the gist below , it’s really easy and simple to create a ViewMode class for your view , just add a class that extends from ViewModel() and you are set to go .
ViewModel Factory
By default when implementing a ViewModel in an Activity/Fragment with the help of the ViewModelProvider class, we can’t pass arguments to the constructor of our ViewModel
If you add argument in constructor you have to create your own implementation of ViewModelProvider.Factory to create your ViewModel instance.
I recommend checking out this article for further details on why we need the ViewModel Factory and how to implement it .
LiveData
LiveData is an observable data holder class. Unlike a regular observable, LiveData is lifecycle-aware, meaning it respects the lifecycle of other app components, such as activities, fragments, or services. This awareness ensures LiveData only updates app component observers that are in an active lifecycle state
Here below we have an example of how to use LiveData with ViewModels . You can fin a more elaborate examples in the app linked below .
And Observing on it is as just easy with the observe method which takes two parameters , the LifecycleOwner and The observer that will receive the events.
A Repository is a bridge between a ViewModel and the data
In addition to being the bridge, a repository can be accessed by any ViewModel that wants to use its logic. It can also combine the logic from multiple data sources.
For a real use case that usually translates to having two data sources , your API and local sources . A repository is the single source of truth .
Kotlin Coroutines
A coroutine is a concurrency design pattern that you can use on Android to simplify code that executes asynchronously.
Kotlin coroutines are a great way of running long tasks that can block the main thread and suspend functions is the backbone of it .
Suspend functions
A suspend function is a regular function except for the addition of the suspend keyword and has some specifications such as :
- A suspending function is simply a function that can be paused and resumed at a later time.
- They can execute a long running operation and wait for it to complete without blocking.
- Suspending functions can only be invoked by another suspending function or within a coroutine.
The code below is an example using a suspend function
Dependency injection with Dagger 2
I will not talk about dependency injection and go into details of dagger2 implementation simple because it needs it’s own article since it can be a little bit complicated at first .
If you are not familiar with the design pattern dependency injection or Dagger , There are a lot of articles out there that already talked about this
I don’t have any specific article or tutorial to recommend but a google search will be a good start .
I have added a sample project which implements MVVM with Coroutines, Android Architectural Components and Dagger 2. any kind of feedback or comments is appreciated.
Hopefully this article was helpful , Thank you for your time.
