Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>To answer this: </p> <blockquote> <p>The original below makes no sense to me because it releases the aTableViewController before adding it as a subview</p> </blockquote> <p>You mentioned:</p> <blockquote> <p>it also makes self.tableViewController = aTableViewController; the tableViewController is synthesized at the top like this: @synthesize tableViewController=tableViewController_ I dont know where it comes from since it is not referenced anywhere else in the project.</p> </blockquote> <p>Most likely, if you look in the header file, you'll see a line like this: </p> <pre><code>@property (nonatomic, retain) tableViewController; </code></pre> <p>This is a "Declared Property" in Objective-C. Declared properties provide a super-convienient way of getting/setting ivars with common patterns (such as retaining any value assigned to them). </p> <p>From the documentation: </p> <blockquote> <p>The Objective-C declared properties feature provides a simple way to declare and implement an object’s accessor methods.</p> </blockquote> <p>You should definitely read the introduction documentation here: </p> <p><a href="http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProperties.html" rel="nofollow">http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProperties.html</a></p> <p>Properties wrap up a bunch of common pattern in tried-and-true ways. </p> <p>For example, consider someone's (naive) potential implementation of a setter method which automatically retains the value assigned to it: </p> <pre><code>- (void) setSomeIvar:(SomeObject *)value { [ivarValue release]; ivarValue = [value retain]; } </code></pre> <p>This seems OK upon first glance, but consider the following code snippet:</p> <pre><code>1: SomeObject * foo = [SomeObject new]; 2: [bar setSomeIvar:foo]; 3: [foo release]; ... </code></pre> <p>(later, potentially in some other method, where foo is the same foo as above):</p> <pre><code>4: [bar setSomeIvar:foo]; </code></pre> <p>What would happen here? Well, in line 1, the retain count is +1, in line 2, it's +2, line 3, +1, then, later, in line 4, we inadvertently released the object before we assigned it to the ivar and retained it, so this code would error on that line. </p> <p>The more-correct code would be something like: </p> <pre><code>- (void) setSomeIvar:(SomeObject *)value { if (ivarValue == value) return; [ivarValue release]; ivarValue = [value retain]; } </code></pre> <p>However, the patterns move beyond even this simplistic example. </p> <p>So, properties are super convenient, and wrap up all this complexity into something more reliable and readable than otherwise possible. </p> <p>They also make it much easier to make sure you're releasing everything you're supposed to be in your <code>dealloc</code> method. Simply look at the header file for all properties marked (...retain...) and make sure they're getting released in the <code>dealloc</code>. Also, for <code>UIViewController</code>s in particular, and their subclasses, any retained properties marked with <code>IBOutlet</code> should be set to <code>nil</code> in <code>viewDidUnload</code>.</p> <p>When I first started using Objective-C I didn't really use properties - and I suffered for it. Once I understood them and started using them they made my life MUCH easier. </p>
    singulars
    1. This table or related slice is empty.
    1. POI'm getting EXC_BAD_ACCESS trying to use my subclass of UITableViewController
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USSteve
    1. USSteve
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POI'm getting EXC_BAD_ACCESS trying to use my subclass of UITableViewController
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. This table or related slice is empty.
 

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