An application architecture is a consistent plan that needs to be made before the development process starts. This plan provides a map of how the different application components should be organized and tied together. It presents guidelines that should be followed during the development process and forces some sacrifices that in the end will help you to construct a well-written application that’s more testable, expandable, and maintainable.
Good architecture takes many factors into consideration, especially the system characteristics and limits. There are many different architectural solutions out there, all of them with pros and cons. However, some key concepts are common between all visions.
Until the last Google I/O, the Android system didn’t recommend any specific Architecture for application development. That means that you were completely free to adopt any model out there: MVP, MVC, MVPP, or even no pattern at all. On top of that, the Android framework didn’t even provide native solutions for problems created by the system itself, specifically the component’s lifecycle.
So, if we wanted to adopt a Model View Presenter pattern on your application, we needed to come up with your own solution from scratch, writing a lot of boilerplate code, or adopt a library without official support. And that absence of standards created a lot of poorly written applications, with codebases that were hard to maintain and test.
After 12 long years, the Android team finally decided to listen to our complaints and to help us with this problem.