Android MVVM Architecture Simplified
In modern software development, writing Graphical User Interfaces (GUIs) from scratch is uncommon due to the time it takes and the redundancy it entails. Instead, developers rely on preexisting components to achieve their desired outcomes, whether it’s rendering UI elements or performing business logic.
While Object-Oriented Programming (OOP) allows for easy utilisation of external code, it can also result in tight coupling between components, leading to what is commonly referred to as “spaghetti code.” An example of tight coupling is when UI, business logic, and data handling are all intertwined within a single view, such as an activity or fragment.
To address these challenges, Google recommends the Model-View-ViewModel (MVVM) architectural pattern for Android app development. MVVM is just one of many GUI architectures used to separate the concerns of UI (displaying data), business logic (processing data), and data handling (where and how to obtain data). By adopting MVVM or similar patterns, developers can achieve better code organisation, maintainability, and reusability in their Android applications.
A well architected app is modular (loosely coupled) hence reusable, scalable and testable. For example, if your app was loosely coupled enough you could replace components (like recycler view with compose lazy list) without breaking the codebase.
In addition to these benefits, MVVM is also supported by the Android Architecture Components, which are a set of libraries that make it easier to develop Android apps with good architecture.
The Layers
Consider when building a house, you build in layers else the structure won’t stand, e.g. you build foundation first and roofing latter. Architecture is the skeleton of the application.
View
Views, like Activities and Fragments, are responsible for displaying the user interface (UI) and handling user interactions. They should only contain UI-related logic, such as animations, input validation, and navigation. The data to be displayed is derived from it’s view model.
ViewModel
This is the bridge between view and business logic, it provides view with data to display and handles UI data manipulation (Create, Read, Update and Delete) requests. It gets data from model.
view classes subscribe to viewmodel such that when data changes it gets notified and is updated with no extra effort. This is achieved with an architecture component called LiveData.
Model
It represents everything that has to do with the data of an Application. It also consists of the data logic — local and remote data source, model classes, repository. Logic about where and how to get data is stated here.
The repository design pattern can be implemented here to provides an abstraction layer between the data sources (such as databases, network services, or local storage)
