Creating a Compound View in Android


Often, when developing Android applications, groups of views tend to be used in multiple places. In order to make things easier, it is considered good practice to encapsulate them in a custom compound view. This allows the same custom view component to be reused throughout the app.

A compound view or compound component is just a view composed of a group of views. This tutorial focuses on building a very basic compound view and defining some methods that change its state.

Creating the Compound View

Creating a Compound View is, in some respects, somewhat similar to creating a new Activity. A new class is created which contains all the view’s children and some methods to manipulate them.

To get started, we’ll first create a new XML layout file in /res/layout/view_article.xml. This will contain the compound view’s children:

Next, we need a class to inflate our new Article View. For simplicity’s sake, we’ll extend a basic RelativeLayout and define our child components. When the view is added to an Activity, it will basically act as a RelativeLayout and allow developers to customize it accordingly.

It is considered best practice to handle the instantiation of our UI components in the onFinishInflate() method in order to prevent any NullPointerExceptions, especially when using ImageViews with large Bitmaps.

At this point, our new Article View doesn’t really do anything special except displaying its children components. As a result, we’ll add some custom methods to manipulate its states:


Now that the ArticleView is complete, we just need to add it to an Activity. We will first add it to the Activity’s layout XML file:

Finally, we initialize it in the Activity and make use of it’s methods in order to change the ArticleView’s state:


Get the full sample project here.


Share this on:

MVP for Android

Why use the MVP pattern?

One of the problems with traditional Android development is the tight coupling between Activities and business logic. This tends to make testing, extensibility and maintenance rather difficult.

The main idea behind using MVP is to take abstract away most (or all) of the business logic into separate entities (presenters) and only keep the UI logic in Activities.

There are many different types of MVP implementations for Android out there, this article only focuses on the basic principles behind them.


The presenter is a separate class that contains the business logic and a reference to its associated view.

The view itself is abstracted away through an interface. This is implemented mainly to allow the view to be mocked in a unit test or replaced with any other view that implements this particular interface.


The view is defined as an Interface which can be implemented by any Activity, Fragment or any type of Android View. This view contains methods that handle all UI logic.


The last step is to link everything together: a new Activity is created which holds a reference to the presenter and implements the View Interface.


Get the full sample project here.



Share this on: