Discover architecture components
If you’re taking this course, it’s because you're getting fairly far along in developing mobile apps for Android. As you develop apps, you might find yourself asking the question: Is there an optimal software architecture for developing Android apps?
How did you know?! Because it’s true that sometimes, my controllers (activities and/or fragments) seem to me to be a bit too big. 😓
Exactly! This phenomenon, known as massive view controller, occurs when one of your controllers (activities and/or fragments) contains too much code, and becomes almost unreadable, or even unstable and virtually untestable.
It’s true that I tend to write a lot of things in my activities. But that said, the smallest feature in an Android app takes up many lines of code!
We agree! 😄 As you have probably already noticed on Android, your controllers have a fairly unique life cycle. That’s because they can be destroyed at any time, taking with them all the data that they contained. This may occur during screen rotations from landscape to portrait, when a telephone call arrives, or when the phone has no more battery. These cases are very complicated for us developers to handle.
Early on, Android developers were left to their own devices, and tried to apply existing architectures onto their projects, following development best practices like separation of concerns (SoC) as best they could.
Some developers have even decided to dispense with MVC architecture and opt for cleaner architectures like MVP, MVVM, or Clean Architecture, which vary in how widely they are adopted by the Android community.
It was in this tense environment that the teams at Google decided to release a set of libraries in late 2017 to more easily create apps that were robust, testable, and maintainable over time... which they called: The Android architecture components!
Founding principles of the architecture components
To create the best possible architecture for an Android app, architecture components are based on two principles:
Controllers (activities or fragments) should be used only to manipulate the graphical user interface (creating, updating, etc.) and interact with the operating system (launching a new activity, for example). That’s it! The rest of the business code must be pushed into separate classes.
The graphical user interface should generally be updated from a class template (POJO, preferably persistable, and reflect it (modeling) as faithfully as possible. The goal is to cope with a loss of internet connection or the app destruction, by recovering the persisted model directly from the storage on your phone (from a database, for example 😉).
Try to always keep these two principles in mind when you're developing an Android application. This will allow you to naturally ask the right questions in terms of the architecture.
Elements of the architecture components
To streamline the controllers (activities and fragments) of your Android applications as much as possible, certain actions are moved into dedicated classes. Thus, Android’s teams have chosen to offer the following architecture:
The controller: Your controller (activity or fragment) will be dedicated to manipulating your GUI - nothing more, nothing less.
The ViewModel: The controller will, however, implement a class of the type ViewModel, whose role will be to provide the controller with data used by the GUI. One of the unique features of the ViewModel class is its ability to survive changes in configuration such as the rotation of the screen without losing its data.
LiveData: The data present within the ViewModel will be primarily LiveData, which is an observable data holder class that allows you to more easily observe changes while respecting the life cycle of your application’s activities and fragments.
The repository: Inside each ViewModel, you will find one or more classes of the type repository, a fairly common design pattern. Its role is a bit particular because it serves as a mediator between the ViewModel, and the various data sources.
Data sources: You use different classes to access data inside each repository; more commonly known as data sources. For example, these classes can take be DAOs, such as those that we created in the previous chapters, or even communication interfaces with APIs.
I know, all this is a bit theoretical! You're probably wondering why everything's so split up. In fact, you should be aware that the more your code is cut in pieces, the more scalable, testable, and legible it will be.
If you've only been coding mini-apps so far, the result might not be obvious. However, when your project begins to grow and take up hundreds of thousands of lines of code, you’ll be pleased to have a clean, maintainable architecture - believe me. 😉
So, let’s get serious and implement all this in the next chapter, through SaveMyTrip!
Let's recap!
The principles of the Android architecture components are:
Controllers (activities or fragments) should only be used for manipulating the graphical interface and interacting with the operating system.
The graphical user interface should be updated from a class template, be persistable, and reflect the template's modeling.
The elements of the Android architecture components are: the controller, the ViewModel, LiveData, the repository, and data sources.
