Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You are using/thinking-in the wrong design pattern. </p> <p>Objective-C uses the Delegate design pattern specifically to avoid a proliferation of subclasses. Attributes and identical methods go into a class or limited subclasses while methods that are custom to each use go into a delegate class. </p> <p>For example, the UITableView class concerns itself only with all the attributes and methods common to every table. All the customization goes in the delegate and the datasource (which is just another delegate) objects. The UITableViewController ties everything into the logical view hierarchy.</p> <p>If you find yourself with a large number of similar tables, you should create a hierarchy of delegate/datasource classes to handle the changes. </p> <p>Remember that having the UITableViewController be both the delegate and datasource object is just a convenience and not a requirement. The delegate and the datasource can be in either one or two separate objects which themselves can be in one or more classes. </p> <p>Tables in particular are highly customized. Each table deals with different data that is displayed in different orders in different cells. That means there really isn't a way to escape writing a relatively large amount of custom code. </p> <p>Read up on the <a href="http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html" rel="nofollow">Delegate Design Pattern.</a></p> <h2>Update:</h2> <blockquote> <p>If a subclass adds an additional row (or multiple rows and/or if they're in the middle of the table rather than at an end), the indexing breaks and most of the delegate methods in the superclass no longer work</p> </blockquote> <p>This sounds to me like you are putting model logic in your tableView delegate/datasource. Neither delegate should have to be rewritten just because you add/remove rows or sections. The logic for rows and sections should be in the model object e.g. Core Data, and the delegates should be solely concerned with translating the logical rows and sections of the model into the rows and sections in the tableview. That translation can be done by boilerplate in the vast majority of cases. Any given delegate should be able to display and arbitrary number of different logical tables using the same code. </p> <p>The only real point of customization is usually the tableview cells. Even then, you are looking at a mere handful of changes per table at the most. </p> <p>Look at the Xcode template tableview project with Core Data. It can display a vast number of tables without changing any code because all the changes occur in the Core Data model layer. </p>
    singulars
    1. This table or related slice is empty.
    1. POHow do I reduce code duplication in my Objective-C code?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USTechZen
    1. USTechZen
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTDownMod
    1. COThanks for the answer, but this doesn't help me too much. I know how the delegate pattern works and I realize that a table's data source need not be its delegate. Yet, in many cases, especially with delegate-based on-demand loading, I find that I can't really reuse my logic and need to write it again. See the example above with a form table view where I want to share behavior from the superclass but add additional rows.
      singulars
      1. PO
      1. USBill
    2. CO@Bill -- See my update. I think you maybe putting model logic in your tableview delegates which would explode their complexity and degree of customization. Moving the model logic to the model layer object outside the tableview delegates would solve your problem. I write a lot of tables and I often write 30 lines of code or less in the controller,delegate and datasource combined for each tableview. All my custom logic is in my data model where it should be.
      singulars
      1. PO
      1. USTechZen
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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