Xebicon 2013__cc In Aa

A demonstration of the "Custom ViewGroup" advice given during the Clean Code in Android Apps talk of XebiCon 2013.
Alternatives To Xebicon 2013__cc In Aa
Project NameStarsDownloadsRepos Using ThisPackages Using ThisMost Recent CommitTotal ReleasesLatest ReleaseOpen IssuesLicenseLanguage
3 years ago13otherKotlin
All Base Adapter528
6 years ago5apache-2.0Java
Adapter terminator, including DataBinding, any ViewGroup, list(Rv, Lv ). Write Adapter, it is enough .Adapter终结者,包含DataBinding,任意ViewGroup,Rv、Lv列表。写Adapter,有它就够了
3 years ago2apache-2.0Kotlin
ViewGroup backed by RecyclerView.Adapter = magic
8 years agoapache-2.0Java
A single adapter implementation for any scrolling view or ViewGroup.
Adapter Databinding11
3 years agoapache-2.0Kotlin
Xebicon 2013__cc In Aa9
10 years agoJava
A demonstration of the "Custom ViewGroup" advice given during the Clean Code in Android Apps talk of XebiCon 2013.
7 years agoJava
a samples of ListView
Android Stacklayout2
9 years agomitJava
Custom ViewGroup of which the top element can be swept away.
Gsectioned Recyclerview2
4 years agomitKotlin
Biblioteca criada de modo a facilitar a criação de um RecyclerView com seções, algo muito comum em diversas aplicações.
5 years agoJava
Alternatives To Xebicon 2013__cc In Aa
Select To Compare

Alternative Project Comparisons

List Item Custom ViewGroup Example

This is the code example to go with a subtopic of the Clean Code in Android Apps talk I gave at XebiCon 2013. It demonstrates why I recommend using a custom ViewGroup for your ListView's child views.

The app itself is a simple contacts list (Screenshot). It's implemented as a ListView with a single kind of child view. There's a little bit of conditional logic in the presentation of the list items:

  • The email and street address fields are not shown if they have no data.
  • If there's no name in the Contact record, the email address is shown in the name field and the email address field is not shown.
  • If there's neither a name nor an email address in the Contact record, a default value is shown in the name field.

It turns out that even these three simple rules make for a sizeable blot of code. This is not pretty code, but it's pretty unavoidable. Essential complexity.

You should start by checking out the 1-_naieve_adapter branch. This serves as the "bad" example, where all the conditional logic is right inside the getView(..) method. The Adapter class mixes the View and Controller responsibilities indiscriminately.

The 2-_ViewHolder_pattern branch demonstrates how using a ViewHolder doesn't really change anything. It's a performance optimization to avoid unnecessary calls of findViewById(int), but the adapter class still mixes responsibilities and getView(..) is still a mess.

The 3-_custom_ViewGroup branch shows the approach I advocate. It has a number of benefits:

  • The getView(..) method is now very straight forward and the Adapter class is much cleaner. The clarity gains grow exponentially with the number of different view types the Adapter presents, in this case just one.
  • The presentation rules for the list item are implemented within the new ContactView class. It's no prettier, but it's isolated from all the other things and in the tightest scope it needs to be aware of.
  • A ViewHolder is not needed, the View references are cached directly in the view class. The view's tag is not used.

Finally, the 4-_better_custom_ViewGroup branch improves on the previous by using a <merge/> as the root element of the custom view's layout xml. This moves the coupling between the custom view class from XML (root tag) to Java code (R-reference). The adapter class no longer has to inflate XML, it can simply new up an instance of ContactView. This is even simpler to work with.

For a detailed exploration of this issue, read ViewHolder considered Harmful on the Xebia blog.


Copyright 2013 Xebia Nederland B.V.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at


Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Popular Viewgroup Projects
Popular Adapter Projects
Popular User Interface Components Categories
Related Searches

Get A Weekly Email With Trending Projects For These Categories
No Spam. Unsubscribe easily at any time.