Question

I’m not sure if this is just something that is up to developer opinion but I am creating an android app and have a Listview that displays a custom view. My layout basically consists of a View (as an xml resource file and a class that derives from the view that is the root), a Domain Model object (has the data to be bound to the view) and an adapter which derives from BaseAdapter that binds the data from the Domain Model to the View in the getViewMethod as follows:

Model: SampleItem
Custom View: SampleView
Adapter: (code below)

   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;
}

This is how I’ve always seen it done, but I wonder is this the right way to do it.

My thought, coming from a different approach to data binding, is that the actual view class doesn’t have a concept of what it’s model is, and diverting the control to how data is bound to it to an adapter class that may not exist if moved elsewhere.

I was thinking that the custom view class has a reference to the object that is bound to it and in it’s constructor it populates the view based on the data. So the adapter is essentially a shell class that only does this:

   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;
 }

And the actual constructor for the view would know its model and populate itself as opposed to the Adapter doing work that seems outside of it’s responsibility.

Answer 1

The adapter should do it. Two reasons.

1) CursorAdapter#bindView: it’s defined in the framework. It’s idiomatic and it will be what other android programmers would expect to see while reading your code. IMHO keeping things idiomatic improves code maintenance and legibility.

2) The way AdapterView classes work in android is that they reuse the Views returned from the adapter. This is so that a lot of new objects aren’t created during scroll/flick/etc. animations and UI events. In order for that to work the AdapterView passes that View back to the adapter and expects that view to be reused. IMHO the intention and expectation is for the Adapter to handle updating and rebinding that View. If you attempt your method and keep the binding in the Views constructor then the only time data binding would happen would be in the constructor. You would then need to move that binding into a separate function possibly cluttering the class interface and with inheritance getting into other problems.

For me, I prefer that a View only care about how to display something. That’s all the responsibilities I really want it to worry about. I think that’s enough since some views can become quite complex. I like to leave it to other classes to worry about telling the View what it should be displaying and where that data should be coming from. Sometimes this means very simple bindings, i.e., calling toString() multiple times in a row. However, it decouples the data that is being displayed from the underling data which allows for one to change with the possibility of reusing the other.