It may just be coincidence, but Steve happens to be the one that answers most if not all of my questions, so I'll start with Hey Steve !!!

I'm wondering if you see anything problematic in this design using the IGGridView.

My picture was too large to place in the forum window, but you can take a look at it here.

https://drive.google.com/file/d/0B3MfvEtIvIvxRDlfX2M0UUk0TU0/view?usp=sharing

In learning about how to use the gridview, I've posted a number of small topic focused posts, but those have been somewhat misleading to the actual application because they were an oversimplification.  So here is a more robust and complete example than in previous posts.

We're building our gridview table via a parsed xml structure from file.

That xml will dictate the following…

For each section header:

• the section headers
• the order of the section headers.
• the title on the section headers.
• the action method(s) that should be called when various UI elements on the custom section header are tapped.

For each section detail:

• what the first columns friendly text title is in the gridview (as opposed to the coredata field name)
• what fields are editable,
• what their colors and fonts are
• what order they'll appear on the grid section detail

We like the XML dictating the layout of the grid, and what it's datasources are, to minimize any recompilation and redistribution of the app.

It's also much easier for non-programmers to modify the XML to change the grid structure rather than to change the code.

Each section header and detail in the grid will represent data from a particular Core Data table.

Since the grid needs to work with a single datasource, I'll have a data structure that aggregates and arranges all the various datasources into a single structure that I can then use to build each section and details.

This particular usage scenario for the IGGridView does NOT require

• filtering
• sorting
• searching
• reordering
• inserting rows
• deleting rows

The structure is fixed and determined up front by the xml, the grid is then built and populated, and the user may then edit some of the values in the second column's cells, depending on what their XML definition indicates it should be editable or not.

There certainly are use cases for the datasource helpers, but since I'm starting with our most complex needs first, I need maximum flexibility in code over simplicity.  I may at some point need custom cell types, and will definitely need custom section headers.  For various reasons, I don't want to be limited by the datasource helpers.  If app features/requirements change in the future, i'd have rather taken the most flexible path up front than try to tear apart and implement it later.