Accessing ListView child Views 

do not forget the recycler

Accessing ListView child Views: do not forget the recycler

최근 나는 ListView 위젯을 기반으로 한 커스텀 뷰를 개발하였다. 이 커스텀 뷰에서 —이제 CustomView라고 부르도록 하겠다 — , 나는 리스트뷰의 모든 자식 뷰들 —이것을 ListItemView라고 부르도록 하겠다. — 의 속성을 CustomView의 메소드에서 변경해야 했다. 다시 말해서, 나는 CustomView#setThing(int)에서 리스트뷰의 모든 자식 ListItemView에 ListItemView#setThing(int)를 호출하여 요청을 보내야 했다.

Recently I’ve been developing a custom View based on the ListView widget. In this custom View — we will name it CustomView, I had to change the property of all ListView child Views — we will call them ListItemView — from a method in CustomView. In other words, I had to forward calls from CustomView#setThing(int) to all ListView child ListItemView by calling ListItemView#setThing(int).

# Method 1

이것을 하기 위한 명확하고 직접적인 방법은 모든 ListView 자식들의 setThing(int)를 호출하는 것이다. 이렇게 하는 것의 큰 문제는 recycler에 있을 뷰들은 제외되고 ListView에 현재 부착된 뷰들만 얻을 수 있다는 것이다. 나는 오직 하나의 타입만 표시되고 있을 때 ListView의 recycler가 비어있지 않을 수 있는지를 체크하기 위해 코드를 찾아보지는 않았다. 하지만 나는 이 방법을 크게 지지하지는 않는다. ListView의 recylcler에 대한 가정을 하고 문서화되지 않는 행동에 의지할 수 있다.

One obvious and straightforward way to do that is to call setThing(int) on all ListView child. The main issue with doing that is you will only get the Views that are actually attached to the ListView, not the ones that may be in the recycler. I haven’t looked at the code to check whether a ListView recycler can be non-empty when only displaying a single type of item but I’m really not a huge fan of this method. You are basically making assumptions on the ListView’s recycler and relying on an undocumented behavior.

# Method 2

ListAdapter#getView 메소드에서 만들어진 새로운 뷰을 가지는 WeakReference<View>의 리스트를 사용한다. 이 방법은 모든 ListItemView들을 변경할 수 있다는 장점을 가지지만 화면에 보이지 않는 (recycler에 있는) 뷰들까지 변경하게 된다. 게다가 WeakReference<View>의 목록에서 null인 참조를 제거하기 위해 능동적으로 관리할 필요가 있다.

Use a list of WeakReference<View> that is populated whenever you create a new View in the ListAdapter#getView method. This method has the advantage of making sure you will modify all of the ListItemViews but may also modify Views that are not even displayed on screen (in the recycler). Moreover, you need to actively manage the list of WeakReference<View> to remove the references that are now null.

# Method 3

어떤 뷰들이 스크린에 표시되고 있는지 알기 위해서 RecyclerListener와 이전 방법을 조합을 사용할 수 있다. 고맙게도 당신은 어떤 뷰들이 recycler에 있는지 알 수 있으므로 getView에서 재사용될 때 업데이트 되도록 표시하고, 뷰들이 스크린에 표시될 때 업데이트를 한다.

Use a combination of RecyclerListener and the previous method to know which Views are on screen. Thanks to it, you can know which Views are in the recycler, flag them to be updated the next time they are reused in getView, and which Views are on screen, update them now.

[0]: http://developer.android.com/reference/android/widget/AbsListView.RecyclerListener.html

간략히

AbsListView.RecyclerListener

http://developer.android.com/reference/android/widget/AbsListView.RecyclerListener.html