Most of my view controllers had collection/table views that present results from a web service call. ArrayDataSource only supports arrays, so I had to fetch and parse from the server before creating the data source.

I needed pagination. That means my datasource should be able to grow.

I needed some modification features: move, replace, delete, etc…

I could easily handle the first issue by creating the data source after the network call finished. The view controller would be the usual place for that code, but I wanted to keep it light.

The second issue could be handled by replacing the array with a bigger one each time I had to add a page.

The last was the trickiest. I was starting to have a lot of code outside the data source only to mutate it. That code should go inside the data source.

As you can see I decided to separate the parsing code from the fetching code. The idea is that you might have different service results for each calls. For example, one for shops, one for locations, etc…

As the name implies, a data source should provide data to other object, frequently a view or view controller. So should it know how to create views? No it shouldn’t. That’s why Chris added that configureCellBlock.

Just a quick note. I would love to know the reason behind tableView:cellForRowAtIndexPath:. I mean, why did Apple decided it should be the data source’s job to create cells?

Let’s imagine you have a collection view of Flickr photos, as you scroll down the next page of items is appended to the bottom. When you tap one item you present a new view controller with a full screen collection view that shows the same photos. As you (horizontally) scroll to the end of this collection view the next page should be appended to the right.

You want both collection views to share the same data source. It’s the same data. And you want to reflect the same state on both as the user goes back and forth. But if the data source owns the cell identifier and configuration block you cannot share it between collection views. The cells are completely different.

One last thing you might notice is that AbstractDataSource still conforms to UICollectionViewDataSource and UITableViewDataSource. I figured that the data source needs to be able to define the number of sections and rows. If you have a DictionaryDataSource with { title : array } pairs for example.

It doesn’t make sense for a RemoteDataSource to be modified, and the code to remove an item from ArrayDataSource will certainly be different from SQLTableDataSource.