Support for Multiple Sections

[thebarndog]

Love this library, it was very cool to take it apart piece by piece and see how it all worked.

I noticed though that it doesn't seem to have support for multiple sections in a table view (given that numberOfSectionsInTableView: isn't implemented) or multiple subclasses of UITableViewCell since just one template cell is passed to the init function. I built an analogous helper class for UICollectionView and I added in support for what I just mentioned. However, what I'm stuck on the most and hoped that you could give some insight into, is how to model the data.

In CETableViewBindingHelper, the data property is just an NSArray so it's easy to index right into that array and it seems like any table view that would use this project can only have one section in it, which makes sense since it seems more of a fun example project (albeit a kickass one).

So the question is, what is the best way to model the data provided to the helper class so that it's 1) easy for the user to populate information and 2) maintains some level of abstraction.

The easiest and most obvious way I can think of is have a CEObservableMutableArray instance that has a dictionary in each spot. This dictionary would look something like:

@{@"header":someHeaderModel, @"footer: someFooterModel, @"items:@[@{@"reuseIdentifier":@"REUSE", @"models":@[anObject, anObejct2] } }

but to me that seems to cumbersome from the perspective of the end user.

My next approach was to build an abstract class hierarchy that went like this:

BaseModel @property (nonatomic) NSArray *sections;

Each spot in section is an instance of a SectionModel class which would look like:

SectionModel - dictionary of supplementary views indexed by kind - NSArray of items

Each item would then be an instance of ItemModel

ItemModel - NSString *reuseIdentifier

• id viewModel (this is what gets passed into bindViewModel:

A better way to go about it would be to remove BaseModel completely and have a list of SectionModel's but both ways still present the same problem; there seems too much burden on the end user of the software to construct each ItemModel and SectionModel themselves.

The ultimate goal of course is to have the binder be able to dequeue cells and supplementary views in an easy and consistent way such as self.data[indexPath.section][indexPath.row] and I think that goal somewhat informs the decision to make an abstraction over the data so that the user can only provide say an array of SectionModels and in that way, the helper would be able to support it. If you have any suggestions as to my quandary, it would be much appreciated.