MoviesPreview: the Android app architecture - the Repository
IMPORTANT: this article is out of date. There is a more updated one here.
In the root post of this series, I exposed how the architecture of MoviesPreview is implemented on a high level. In this post, I’ll try to explain the singularities of the repository layer and how it is implemented.
The repository pattern is a well-known pattern, widely used in Android applications. The core concept of the pattern is to isolate the data sources to simplify business logic. Generically speaking the repository pattern consists of an abstraction layer (the repository) that provides access to a single entity of the domain by allowing the upper layers to query and update the state of that entity. The way that the entity data is stored is hidden to the upper layers — that way, the responsibility of the upper layer is reduced to just process the data ignoring the source that is providing that data.
Principles
- Provide access to a single entity of the domain. This means that there is one repository per domain class present in the application’s architecture.
- Hide the multiplicity of data sources, for instance, a local cache and a remote API.
- If there is a caching mechanism in place, the repository takes care of syncing that local cache in order to ensure that the application data is up to date.
The repository in MoviesPreview
- Local Data Source: it is basically a local database that stores the data locally on the device. It is basically a local cache that is implemented using the Room library — every time it is queried for a particular data, the data source verifies if the local data is present and if it is not too old, and returns the data or null based on that premise. In order to achieve this the data source stores the information with a timestamp that it is compared against a refresh time in order to determinate if the data can be used or should be updated before using it.
- Remote Data Source: this is a super simple layer that is implemented using Retrofit. The core responsibility of this data source is simply to query the remote API in order to retrieve the data or to update the data.
An example: the Movie Details
In order to be able to present this screen to the user, the application needs to retrieve information about the movie being shown. The sequence of events that happen in the repository layer can be simplified with the following diagram:
- MovieDetailRepository is queried to retrieve a MovieDetail of a movie identified by a particular id.
- MovieDetailRepository queries MovieDetailDB in order to fetch the MovieDetail.
- MovieDetailDB interacts with the Room database in order to get the MovieDetail.
- If the MovieDetail is not present — or if it is out of date — MovieDetailRepository requests the MoveDetail to MoveDetailAPI.
- In the end, MovieDetailRepository updates the local storage with the obtained MovieDetail and returns it to its client.
This is in a very simplified way what happens when the upper layers request the data to the repository.
You can follow the code from here.
