Why Others Ignore GUI Architectures

It is quite likely that the vast majority of Android apps do not use any of these GUI architectures.

In some cases, this is unintentional, insofar as the developer(s) of the app do not know about such architectures or have not considered them. Not everybody has equal education and experience, and that will be reflected in the tactical and strategic development decisions that they make or participate in making.

However, in some cases, there are clear reasons why a classic MV* GUI architecture is unsuitable.

Atypical Apps

These GUI architectures have been refined for “typical” app structures:

• You have some data (local or remote)
• You want to display that data to the user (in collections or for individual items)
• Often, the user can manipulate that data, adding to it, modifying it, or perhaps deleting it
• Sometimes, the data can change on the fly from outside of the app (e.g., push messages, other forms of server-centered updates)
• You want those data changes to flow back to the data source, plus update the UI of the app as needed

Lots of apps fit that general description. At the same time, lots of apps do not fit that general description, such as:

• Many types of games
• System-integrated tools, like soft keyboards and VPNs
• Musical instrument simulators
• Terminal emulators
• Camera apps
• Calculators
• And so on

Some of these will have their own architecture patterns, perhaps tied to libraries or frameworks. Game development, for example, has its own approaches, often embodied in toolkits like Unity3D. Those approaches may not resemble the MV* architectures that you might use in, say, a social network client.

It is up to you to decide how well these sorts of GUI architectures fit your particular type of app.

YAGNI and Overhead

The bigger the app, the more likely it is that you will gain benefit from a formal GUI architecture. Such apps are more likely to have more developers and be used for more time, where a formal GUI architecture can yield benefits.

Conversely, the smaller the app, the less likely it is that a formal GUI architecture is necessarily worth it. Or, as the saying goes, “you aren’t going to need it” (YAGNI).

Most of the sample apps in this book, like the sample apps from The Busy Coder’s Guide to Android Development, skip the formalities. That is because they are samples of how to use particular APIs and usually have little code beyond that.

A well-architected app is likely to have more code than an equivalent app that “just gets the job done”. The next chapter will profile a simple checklist-style “to-do” app built using the MVI architecture. As you will see, the architecture itself dictates that many more classes be created, above and beyond what might be needed for the core functionality.

No Obvious User Benefit

The counterpart to this issue is that the user rarely, if ever, benefits directly from the use of a formal GUI architecture. Developers may benefit, and their organization (where relevant) may benefit. However, the user is not necessarily going to see anything different. A note-taking app, or a chat client, or a video player, should look the same to the user whether the developer(s) used MVC, MVP, MVVM, MVI, some other GUI architecture… or no specific GUI architecture at all.

It is entirely possible that bugs will exist in an informally-developed app that would not exist had the developers chosen and implemented a formal GUI architecture. However, there is no guarantee that bugs will exist in an informally-developed app. Similarly, there is no guarantee that using an MV* architecture will eliminate all of your bugs by magic. A development team that doesn’t pay much attention to GUI architecture — instead choosing to invest that time in an awesome test suite — may have a better app in the end than a team that focused heavily on the architecture and did a sub-par job at testing.

Choosing a GUI architecture does not give the users any additional features. There are no new marketing buzzwords to tout. The media will not praise the app for its adherence to some GUI architecture. If management thinks that investing in a GUI architecture is slowing down “work that matters”, management might steer developers towards other efforts and away from a formal architecture. Frequently, decisions made on this basis turn out to be bad ones… but management is free to make those decisions.

No Consistency In Definitions

Compounding that latter problem is that it may take a while to figure out how to implement a GUI architecture, as they are very ill-defined. We toss around terms like “model” and “view” without clear definitions, particularly with respect to concrete scenarios and Android apps. As a result, not only does the development team need to debate which architecture to use, but also what that architecture really means in practice.