Activities are not Views

There are only two hard things in Computer Science: cache invalidation and naming things.

— Phil Karlton

The Single Responsibility Principle is a classic software design principle in computer programming. It states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class (i.e. hidden behind an interface).

In Android development, this type of information hiding is particularly useful when creating the boundary between classes that import Android dependencies and those that do not.

The view layer should be the only layer that cares about the framework. The presenter or view model layer and the domain model layer should be comprised of pure Java objects.

Many implementations of MVP or MVVM will create an interface for the Activity and call this the View.

This is problematic for two reasons.

1. It violates the single responsibility principle. The activity should not be the primary driver of the UI. It already has multiple other responsibilities including reacting to lifecycle events, handling user input, and providing access to system services by nature of being a Context.
2. View is an overloaded term. There is already a class (and a rather large hierarchy of subclasses) called View. Introducing a new interface called View creates confusion when reasoning about class responsibilities and interactions.

This is why I think its helpful to think of the the View (layout, compound view, custom view, etc.) whose responsibility is UI only as a separate component from the Activity.

But then the question becomes what do you call the interface that is used by the presenter to communicate with the Activity? The answer is Controller.

This simple name change addresses both problems outlined above and makes it much easier to reason about the responsibilities of each component. The Activity and Controller are still part of the view layer, but the distinction between controller and view is much more clear.

Activities and Fragments are even referred to as UI controllers in the documentation for the new Android Architecture Components.

Another problem is that, these UI controllers (activities, fragments, and so on) frequently need to make some asynchronous calls which may take some time to return. The UI controller needs to manage these calls and clean them up when it is destroyed to avoid potential memory leaks.

What a difference a simple name change can make!

I guess that’s why it’s one of the only two hard things in computer science.

This post is part of a series on clean architecture that explores how classic software design principles can be applied to modern Android development.

If you found this article helpful, please give it some applause 👏 to help others find it. Feel free to leave a comment below.