2011-01-19 2 views
3

이것은 개발자의 의견에 달려 있지만 Android 앱을 만들고 사용자 정의보기를 표시하는 Listview를 가지고 있는지 확실하지 않습니다. 내 레이아웃은 기본적으로 View (XML 리소스 파일과 루트 인 뷰에서 파생되는 클래스), Domain Model 객체 (뷰에 바인딩 할 데이터 있음) 및 BaseAdapter에서 파생 된 어댑터로 구성됩니다. 다음과 같이 getViewMethod에서 볼 수있는 도메인 모델로부터 데이터를 결합 :Android Binding 전략, 어댑터가 작업을 수행해야합니까?

모델 : SampleItem
사용자 정의보기 : SampleView
어댑터 : (아래 코드)

public View getView(int position, View convertView, ViewGroup parent) { 
    SampleView sampleView; 

    SampleItem item = (SampleItem)getItem(position); 

    if(convertView == null) { 
    sampleView = new SampleView(_context); 
    } 
    else { 
    sampleView = (SampleView)convertView; 
    } 

    sampleView.setTitle(item.getTitle()); 
    sampleView.setContentText(item.getContent()); 
    sampleView.setItemRowNumer(item.getRowNumber()); 
    ... //etc 
    return sampleView; 
} 

이것은 내가 항상 그것을 보았던 방법이지만, 나는 이것을하는 올바른 방법이라고 생각합니다.

데이터 바인딩에 대한 다른 접근 방법에서 얻은 내 생각에 실제 뷰 클래스에는 모델이 무엇인지 개념이없고 컨트롤이 데이터가 바인딩되는 방식으로 전환되는 어댑터 클래스로 전환됩니다. 다른 곳에 옮겨지면 존재하지 않을 수도 있습니다.

사용자 지정보기 클래스에 바인딩 된 개체에 대한 참조가 있고 생성자에서 데이터를 기반으로보기를 채 웁니다.

public View getView(int position, View convertView, ViewGroup parent) { 
    SampleView sampleView; 

    SampleItem item = (SampleItem)getItem(position); 

    if(convertView == null) { 
    sampleView = new SampleView(_context, item); 
    } 
    else { 
    sampleView = (SampleView)convertView; 
    } 

    return sampleView; 
} 

그리고 그 모델을 알고 그 책임의 외부 보인다 어댑터하고 작업 반대로 자신을 채우는 것이보기에 대한 실제 생성자 : 그래서 어댑터는이 작업을 수행하는 쉘 클래스는 본질적이다.

답변

3

어댑터가이를 수행해야합니다. 두 가지 이유.

1) CursorAdapter#bindView : 프레임 워크에 정의되어 있습니다. 그것은 관용적이며 다른 안드로이드 프로그래머가 코드를 읽는 동안 무엇을 기대할 것인지를 예상합니다. IMHO는 일을 관용적으로 유지함으로써 코드 유지 보수와 가독성을 향상시킵니다.

2) 방법은 AdapterView이며 안드로이드에서 작동하는 것은 어댑터에서 반환 된 View을 다시 사용한다는 것입니다. 이것은 스크롤/플릭/등 중에 많은 새로운 객체가 생성되지 않도록하기위한 것입니다. 애니메이션 및 UI 이벤트. 이를 작동 시키려면 AdapterViewView을 다시 어댑터로 전달하고 해당보기를 재사용 할 것을 기대합니다. IMHO는 AdapterView의 업데이트 및 리 바인딩을 처리하기위한 의도와 기대입니다. 메서드를 시도하고 View 생성자에서 바인딩을 유지하면 데이터 바인딩이 생성되는 유일한 시간은 생성자에 있습니다. 그런 다음 해당 바인딩을 별도의 함수로 이동시켜 클래스 인터페이스를 혼란에 빠뜨릴 수 있고 상속이 다른 문제가 될 수 있습니다.

나를 위해, 나는 View이 뭔가를 표시하는 방법에만 관심이있는 것을 선호합니다. 그것이 정말로 내가 염려해야 할 모든 책임입니다. 몇 가지 견해가 상당히 복잡해지기 때문에 그 정도면 충분하다고 생각합니다. 나는 그것을 다른 클래스에 남겨 두어 View이 무엇을 표시해야하는지, 그리고 그 데이터가 어디에서 오는 것인지 걱정하는 것에 대해 걱정하고 있습니다. 때로는 매우 간단한 바인딩 즉, 한 번에 toString() 번을 여러 번 호출하는 것을 의미합니다. 그러나 표시되는 데이터와 언더 데이터를 분리하여 다른 데이터를 재사용 할 수있는 가능성을 변경합니다.

+0

이보기는 Android [[이와 비슷한 형식으로] (http://code.google.com/p/android-binding/wiki/Motivation)에서 구현할 수있는 MVVM UI 디자인 패턴과 일치합니다. 전체 MVVM 패턴을 이해하는 데 다소 시간이 걸립니다. – Cel

관련 문제