Building Reusable Android Components with Blueprint

If you’ve read the Intro to Blueprint, you already know that it’s a framework for quickly and easily creating scrolling screens for Android apps without all the boiler plate associated with RecyclerViews. Today we’ll learn how to build the most basic building block of a Blueprint app, a Component.

In Blueprint, each screen is a scrollable list of reusable Components, and each Component is made of three parts: The Model, View and Presenter. Blueprint provides the template classes ComponentModel, ComponentView and ComponentPresenter to represent these parts.


ComponentModel is just an interface with no methods, and is most likely just cruft from a previous version. Any POJO can be a ComponentModel, and ComponentModel may actually just get replaced with Kotlin’s Any class in the future. For now, the only thing you need to know is that any class can be a ComponentModel.


The V of a Component’s MVP is composed of two parts, the actual ComponentView class, and an implementation of RecyclerView.ViewHolder. Let’s take a look at the Header ComponentView from BluePrint’s sample app:

ComponentView Example

As you can see, you create a ComponentView by applying the ComponentViewClass annotation, and using it to specify the ViewHolder class for this ComponentView. Then, on the ViewHolder class, use the ComponentViewHolder annotation to specify the layout for this ComponentView. These annotations generate a HeaderViewBase class, which is where all the RecyclerView related boilerplate will be written for you. For any ComponentView with the ComponentViewClass annotation, the generated base class will always be named with the format: ComponentViewClassNameBase. And, that’s it.

With Blueprint, you don’t ever have to write A RecyclerView Adapter.



All of the repetitive work of creating and binding ViewHolders is written for you by the Annotation Processor.

In this example, for presenting the header, we only need to set two things: the TextView’s text, and whether or not the itemView is enabled or not. So that’s the only functionality you actually have to write into the ComponentView class.

In Blueprint, you only write the code you need.

The rest is generated for you. So convenient!


The ComponentPresenter does exactly what you’d think: It presents Model data into the ComponentView. Here’s the presenter for the header view we saw above:


As you can see, we’re again using an annotation (DefaultPresenter) to do some work. With Blueprint, you can always use any ComponentPresenter you want to present a view. But if a view is going to be presented the same way most of the time, you can set a ComponentPresenter class as its default using the DefaultPresenter annotation, and then you don’t have to build or specify that presenter. Ever. Anytime you use this presenter’s ComponentView (in this case HeaderView), if you don’t specify a presenter, Blueprint will use the default.

Also, notice that the present() function receives both the ComponentView class and the ComponentModel class as arguments. The presenter knows what types of classes they are, so it can cast them, and do the presentation work it needs to do.

And… that’s it. Creating a component is that easy. Of course, you have to build the xml layout for your view, but I’m guessing that’s not a problem for you. Next time, we’ll learn how to use our new Component to build a Screen.

Stay tuned.