Isn’t this MVVM?
Architecture Components have been developed in such a way that when we integrate it into our project, they eventually end up organizing our project in MVVM like architecture. Most important components to look out are –
If we use
ViewModel and Data Binding, then we can call our architecture as MVVM and if we use
LiveData, then it is just MVVM without Data Binding.
Data Binding library was announced back in Google I/O 2015. Using it or not can be developer’s choice to bind
ViewModel with the View.
We have developed the UpcomingMovies-Android project, which demonstrates the use of
LiveData and many other Android Jetpack components in Kotlin language. We referred following projects from github.com/googlesamples –
How is ViewModel different than Presenter?
Many developers do not preserve Presenter on configuration changes like screen rotation. So long-running network calls had to be called again, which shouldn’t be the case. Android does not have anything to preserve the Presenter out of the box. So they made
ViewModel as a component. This
ViewModel component not necessarily means ViewModel of the MVVM but can be very closely related with.
ViewModel attaches to the lifecycle of your
Fragment. This means it is not destroyed on
onDestroy() method but gets cleared only when
Fragment is finishing. So you can say
ViewModel as a Presenter with lifecycle aware feature.
In MVP, it gets difficult to access application context. Here in ViewModel library,
AndroidViewModel is a class which extends from
ViewModel and is nothing but
What is LiveData?
LiveData is a lifecycle aware observable pattern, which emits value only when
Fragment is in
RESUMED state. Have a look at
LiveData does also have
observeForever() method, which is not lifecycle aware and is always in an active state.
We can add multiple
LiveData and whenever a value in it changes, all the added
Observer will get notified.
LiveData are generally stored in
ViewModel so that we can expose data to
ViewModel and add necessary
Expose data through Repository
Data can be fetched from a remote data source or can be stored locally for caching. A Repository isn’t an architecture component but just the way of organizing data communication, same as the way in MVP. A Repository might have only a remote data source or only a local data source or a combination of both. This would vary depending upon the use case. Organizing data communication through the Repository makes it extendable and easy to test.
Local Data Source using Room
Room is a persistence library which provides an abstraction layer over SQLite to allow for more robust database access while harnessing the full power of SQLite. We can communicate to local db by DAOs made using
Room. DAO makes it easy for developers to write a SQLite query in a functional way. Room also has in memory db approach which saves the db until an
Fragment is not finished. See
UpcomingMovieDaoTest.kt in the attached project.
Other Architecture Components to look at
We have also used the
Paging library which makes it easy to load data from a source which supports pagination. It has three abstract classes
PositionalDataSource, which we can extend and use it according to our need. See
UpcomingMoviesDataSource.kt which extends from
PageKeyedDataSource to fetch remote data depending on the page key and if network call fails then it checks for the cached copy in local db using
We have made our first attempt towards MVVM, let’s see how well it is adopted by developers.
We are proud to always keep hands-on latest native tools, and that requires a team of passionate professionals. We’d be glad to help you with full-cycle app development using the latest native tools with our team of professionals. Feel free to contact us with any ideas you have. We’ ll help you translate them into reality.