A better custom ViewGroup

30 Jul, 2013

Jerome P. commented on my earlier post denouncing the ViewHolder pattern. He suggested an improvement to the ViewGroup approach that inverts the direction of dependency between the ContactView and its layout XML file. Instead of referencing the custom class from XML, the Java code now references the layout file using a standard resource reference. This adds further type safety and it means your view class can be completely ProGuarded.

The list adapter implementation becomes more convenient. It no longer needs to use a layout inflater, it can simply new up an instance of the view class:
[code language=”java”]
public View getView(int position, View convertView, ViewGroup parent) {
ContactView view;
if (convertView == null) {
view = new ContactView(context);
// Was: view = (ContactView) inflater.inflate(R.layout.list_item, null);
// continued…
To do this, change the root element of the XML layout to <merge/> and modify the constructors of the custom view group:
[code language=”java”]
public class ContactView extends LinearLayout {
// private field declarations
/** Inherited constructor. */
public ContactView(Context context) {
/** All three constructors invoke this method. */
private void init(Context context) {
LayoutInflater.from(context).inflate(R.layout.contact_view, this, true);
nameView = (TextView) findViewById(;
emailView = (TextView) findViewById(;
addressView = (TextView) findViewById(;
// continued
The complete code for this example has been added to the 4-_better_custom_ViewGroup branch of the android-cciaa repository on GitHub.

Newest Most Voted
Inline Feedbacks
View all comments
8 years ago

using the <merge/> tag is all good if it was a simple LinearLayout. what about views that uses RelativeLayout? i could only think of 2 approach.
1. use <merge><RelativeLayout>. this would introduce a useless parent container after merging/inflate
2. pretend <merge> is a RelativeLayout, i.e. continue using Layout specific attributes on the child view and in the View java class, extends RelativeLayout.
what would your approach be?

8 years ago

This sounds good, but I guess there’s a downside to instantiating the custom view yourself, in that it won’t inherit your theme properties.

Lester Bambico
Lester Bambico
8 years ago

Hi, I came across your post accidentally looking for animation alternatives to ViewAnimator.
Although completely unrelated, I was guilty of using the classic adapter approach and have been suffering performance issues when handling large lists.
I tried implementing your ‘better custom viewgroup’ but stumbled upon a roadblock.
How do you implement this with listeners for lists such as a to-do-list for example where we have a linear layout with an edit text and checkboxes?

James HO
James HO
7 years ago

Last sentence in your first paragraph:
“This adds further type safety and it means your view class can be completely ProGuarded.”
May I ask what it means? I don’t get it.

Explore related posts