|Project Name||Stars||Downloads||Repos Using This||Packages Using This||Most Recent Commit||Total Releases||Latest Release||Open Issues||License||Language|
|Shimmerrecyclerview||3,458||3 years ago||13||other||Kotlin|
|All Base Adapter||528||6 years ago||5||apache-2.0||Java|
|Adapter terminator, including DataBinding, any ViewGroup, list(Rv, Lv ). Write Adapter, it is enough .Adapter终结者，包含DataBinding，任意ViewGroup，Rv、Lv列表。写Adapter，有它就够了|
|Adapterlayout||57||3 years ago||2||apache-2.0||Kotlin|
|ViewGroup backed by RecyclerView.Adapter = magic|
|Universaladapter||53||8 years ago||apache-2.0||Java|
|A single adapter implementation for any scrolling view or ViewGroup.|
|Adapter Databinding||11||3 years ago||apache-2.0||Kotlin|
|Xebicon 2013__cc In Aa||9||10 years ago||Java|
|A demonstration of the "Custom ViewGroup" advice given during the Clean Code in Android Apps talk of XebiCon 2013.|
|Listview||3||7 years ago||Java|
|a samples of ListView|
|Android Stacklayout||2||9 years ago||mit||Java|
|Custom ViewGroup of which the top element can be swept away.|
|Gsectioned Recyclerview||2||4 years ago||mit||Kotlin|
|Biblioteca criada de modo a facilitar a criação de um RecyclerView com seções, algo muito comum em diversas aplicações.|
|Simplemvp_android||2||5 years ago||Java|
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
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:
Contactrecord, the email address is shown in the name field and the email address field is not shown.
Contactrecord, 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
The 2-_ViewHolder_pattern branch demonstrates how using a
doesn't really change anything. It's a performance optimization to avoid
unnecessary calls of
findViewById(int), but the adapter class still mixes
getView(..) is still a mess.
The 3-_custom_ViewGroup branch shows the approach I advocate. It has a number of benefits:
getView(..)method is now very straight forward and the
Adapterclass is much cleaner. The clarity gains grow exponentially with the number of different view types the
Adapterpresents, in this case just one.
ContactViewclass. It's no prettier, but it's isolated from all the other things and in the tightest scope it needs to be aware of.
ViewHolderis not needed, the
Viewreferences are cached directly in the view class. The view's
tagis not used.
Finally, the 4-_better_custom_ViewGroup branch improves on the previous by
<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.