Book Image

Clean Android Architecture

By : Alexandru Dumbravan
Book Image

Clean Android Architecture

By: Alexandru Dumbravan

Overview of this book

As an application’s code base increases, it becomes harder for developers to maintain existing features and introduce new ones. In this clean architecture book, you'll learn to identify when and how this problem emerges and how to structure your code to overcome it. The book starts by explaining clean architecture principles and Android architecture components and then explores the tools, frameworks, and libraries involved. You’ll learn how to structure your application in the data and domain layers, the technologies that go in each layer, and the role that each layer plays in keeping your application clean. You’ll understand how to arrange the code into these two layers and the components involved in assembling them. Finally, you'll cover the presentation layer and the patterns that can be applied to have a decoupled and testable code base. By the end of this architecture book, you'll be able to build an application following clean architecture principles and have the knowledge you need to maintain and test the application easily.
Table of Contents (15 chapters)
1
Part 1 – Introduction
6
Part 2 – Domain and Data Layers
10
Part 3 – Presentation Layer

Introducing the app's architecture

In this section, we will discuss the most common architecture that can be applied to an Android application and how it can be combined with clean architecture principles, and see how we should ideally structure our code base.

In the exercises from the previous chapters, we saw how, for an application that requires the integration of multiple data sources for networking and persistence, we had to put a lot of logic inside the ViewModel class. In those examples, ViewModel had multiple responsibilities, including fetching the data from the internet, persisting it locally, and holding the required information in the user interface. On top of these extra responsibilities, ViewModel also had many dependencies on the different data sources; this means that a change in the networking or persistence libraries would require a change in ViewModel. To solve this problem, our code would need to be split into separate layers with different responsibilities...