Why People Worry About GUI Architectures

Those participating in these debates over GUI architectures will tend to unite against architecture-agnostics, hammering home their belief that you should have some formal GUI architecture in your app — the debate merely is over which one. There are some reasons why formal GUI architecture adherents are strident in their beliefs that such architectures are universally beneficial.

Avoiding Known Problems

GUI development can be tricky. Android GUI development can be trickier than others, with things like configuration changes, tasks, and the like adding lots of edge and corner cases to worry about.

If a popular GUI architecture has been applied to Android — and if those results have been published in a blog post, conference presentation, etc. — part of the work will be to address those tricky bits. Some of the points of contention in the GUI architecture debates are how they handle things like configuration changes, where architectures that handle those things gracefully are considered to be better than those that ignore the problem.

This is not to say that using one of these formal GUI architectures is a requirement to address these problem areas in Android. However, if you implement an Android version of one of these GUI architectures, there is a decent chance that these problem areas will be covered as part of that work.

Consistency Between Team Members

Many Android apps are developed by teams, rather than by solo developers. Team members may switch between working on different parts of the code base at different times, and so while certain areas may have a specific “owner”, that owner may not be the only one to work in those areas. For example, if a critical bug is discovered while an “owner” is away from the office, somebody else may need to step in and fix the bug, so that users are not harmed any longer than is necessary.

Having team members be able to work in any portion of an app’s code base is the reason for overall standards, such as:

• Tabs versus spaces for indents
• Line lengths
• Naming conventions (as opposed to NamingConventions or namingConventions or naming_conventions)
• And so on

At a higher level, teams may elect to standardize on a GUI architecture so that different developers writing different portions of a UI (e.g., different activities) will create similar code. It will be easier for others to adopt and modify that code if it is similar to other areas of the code that were seen previously.

Consistency Over Time

Teams are rarely stable for long. Team members come and go, within the overall organization or departing for greener pastures elsewhere. As such, “onboarding” of team members is important, and having a standardized approach to UI construction, in the form of a specific GUI architecture, can help here.

However, even solo developers are victims of time. Code that might make sense today may make less sense in a year and no sense at all in three years. Developer experience and expertise change, even when the code does not. Having consistent code within an app reduces this problem, in part by making it more likely that the developer will have seen similar code recently. And, adopting a specific GUI architecture means that all the world’s prose on that GUI architecture act as documentation for the project that the developer does not have to write.