Android VIPER Tutorial

If you have some experience with Android development, Architecture Patterns may sound like an old-fashioned concept, which some smart guy has brought to the table just to put you down mercilessly. If I add the word VIPER to the discussion, you might think this sounds like a scam or click-bait. However, I assure you that once you get in-the-loop, you will appreciate how valuable it is to have proper code structure and organization.

In this tutorial, you will get to know the VIPER architecture pattern. You will start by understanding the ideas behind VIPER and how it fits into the Android framework. You will then put it into practice, implementing a sample app that adopts this architecture pattern and illustrates its benefits.

Do not fear the VIPER, just enjoy the bite! :]

Why are you (probably) reading this?

If the above introduction has grabbed your attention, it means you may feel as I used to just a few months ago. To sum up, you may have been developing Android apps for quite some time, reaching a high-level of code complexity and a considerable amount of lines of code in some of your projects. Then, at some point, you have gone through any of the following situations:

1. You get lost refactoring your own code when adding extra features.
2. You realize that there are too many null checks of the same field in different parts of the code.
3. Your classes and/or methods have increased their line length dramatically, largely exceeding the Rule of 30.
4. Some parts of your code are difficult or even impossible to cover with Unit Tests.
5. Your code becomes illegible to any other developer, since you are the only one able to “decipher” your business logic.
6. All of the above. :]

In my case, I was lucky enough to have a colleague around who pushed me to adopt architecture patterns in my projects. Please let me be that colleague for you.

When Android I met Architecture Patterns…

Let me start this section making an announcement upfront: I do not aim to put the blame on Android/Google for the lack of architecture patterns in my early projects. That responsibility is only mine.

It wasn’t me!

It wasn’t me!

On the other hand, my impression is that, until recently, architecture patterns were never a main focus of the official Android documentation. In the old days, app structure was based around the four Android main application components: Activity (most cases), Service, Broadcast Receiver, and/or Content Provider. Later, Fragments came on the stage and became mainstream in many applications.

It was only last year that Google introduced the Android Architecture Blueprints project, in an attempt to give Android developers some organization and structure guidelines. You should definitely have a look at the repo to get a feeling for what’s available as guidance. In addition, Google also released the Android Architecture Components, which is “a collection of libraries that help you design robust, testable, and maintainable apps”. The Architecture Components are now part of Android Jetpack.

VIPER at a glance

In this section you will start diving into VIPER, an architecture pattern related to the Clean Architecture Paradigm. VIPER stands for View, Interactor, Presenter, Entity, and Router. This five-layer organization aims to assign different tasks to each entity, following the Single Responsibility Principle. The basic idea behind VIPER and other Clean Architecture patterns is to create a cleaner and more modular structure to isolate your app’s dependencies and improve the flow of data within your app.

Within the framework of an Android app, the VIPER layers are assigned according to the following scheme:

• The View corresponds to an Activity or Fragment in the app. A goal is to make the View as dumb as possible, so that it only takes care of showing the UI.
• The Interactor takes care of performing any action, when the Presenter says to.
• The Presenter acts as a “Head-of-Department”. In other words, it commands any action making use of the Interactor, tells the View to display content, and orders the navigation to other screens using the Router.
• The Entity represents the app data. In short, it acts likes the Model in the MVP architecture pattern.
• The Router handles navigating to other screens during the app lifecycle.

Further theoretical details on this architecture pattern can be found in the following excellent reference.

Getting started

Enough talk! From this section onwards you will be creating an app named Chucky Facts. The goal is to give you a taste of VIPER in a real app, so that you can see how to handle certain common scenarios under this architecture.

Begin by downloading the starter project using the download button at the top or bottom of the tutorial. The starter project contains the basic skeleton app and some assets.

For didactic purposes, the code has been organized according to VIPER layer names (except for the Router). In a real application, it is common to structure the code in modules; in this particular example, they could be “SplashModule, “MainModule”, and “DetailModule”, for instance.

Build and run the starter project.

As you can see, there’s not a whole lot going on in the app yet.

App definition and description

This app is just a simple viewer which displays information fetched from a REST API. The data source is the well-known Internet Chuck Norris Database, which provides a large list of “facts” about Chuck Norris and his superior status.

The starter AndroidManifest.xml file shows three Activity items, one being SplashActivity which includes the MAIN intent-filter. Both MainActivity and DetailActivity will later extend from BaseActivity, which lets them include a Toolbar.

The app skeleton also includes the Joke class, in the entity package, and JokesListAdapter in the view.adapters package. These implementations do not directly relate to the topic of this tutorial, but feel free to have a look at them and analyze their behavior.

You can take some time to inspect the rest of the starter project and all the features included out-of-the-box (for example, the resource files strings.xml, dimens.xml, and styles.xml).