Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>It's not uncommon to have an <code>-initWithDictionary:</code> method in situations like these. However, all you'd need for the property values would be <code>-initWithObject:</code> -- there'd be no need to translate the Book or Magazine to a dictionary, because you can send <code>-valueForKey:</code> directly to the model objects themselves, as needed. (See NSKeyValueCoding for more details).</p> <p>But I'd be tempted to initialize the CellController with a dictionary containing configuration info, such as headings and footers for the group, as well as settings for individual cells, such as accessory, image file path, key paths for the model values, etc. That would open the door to using a plist file for the config info for your CellControllers (which I'd be tempted to call CellGroups cause they're really just groups of cells -- but that's just me).</p> <p>And then, yes, you'd be trading compile-time checking for flexibility and a reduction in code size. But then again this is a fail-fast scenario (i.e., you'll get runtime errors right away when you goof up a key path), so I think it's a pretty decent trade-off. In exchange, whenever you need to add a new table view, all you'd need to do is create a new plist. And you could initialize your CellGroups with something like this:</p> <pre><code>- (id)initWithObject:(id)anObject configurationInfo:(NSDictionary *)info; </code></pre> <p>(And, yes, you could just stick the object inside the dictionary, but I don't see that as a win, especially if the dictionary is being fetched by reading a plist from the file system.)</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload