Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><strong>When should I add <code>@synthesize</code> explicitly to my code?</strong></p> <p>Generally, if it's required: You will probably never hit a case where it's needed.</p> <p>There's one case you might find it useful, though.</p> <p>Say you're writing both a custom getter and setter, but want an instance variable to back it. (For an atomic property, this is as simple as wanting a custom setter: the compiler will write a getter if you specify a setter for a monatomic property, but not an atomic property.)</p> <p>Consider this:</p> <pre><code>@interface MyObject:NSObject @property (copy) NSString *title; @end @implementation MyObject - (NSString *)title { return _title; } - (void)setTitle:(NSString *)title { _title = [title copy]; } @end </code></pre> <p>This will not work, because <code>_title</code> doesn't exist. You've specified both a getter or setter, so Xcode (correctly) doesn't create a backing instance variable for it.</p> <p><img src="https://i.stack.imgur.com/CkPw4.png" alt="enter image description here"></p> <p>You have two choices for making it exist. You can either change the <code>@implementation</code> to this:</p> <pre><code>@implementation MyObject { NSString *_title; } - (NSString *)title { return _title; } - (void)setTitle:(NSString *)title { _title = [title copy]; } @end </code></pre> <p>Or change it to this:</p> <pre><code>@implementation MyObject @synthesize title = _title; - (NSString *)title { return _title; } - (void)setTitle:(NSString *)title { _title = [title copy]; } @end </code></pre> <p>In other words, although synthesize is for practical purposes never necessary*, it can be used to <strong>define</strong> property-backing instance variables when you're providing a getter/setter. You can decide which form here you want to use.</p> <p>In the past, I've favoured specifying the instance variable in the <code>@implementation {}</code>, but I now think the <code>@synthesize</code> route is a better choice as it removes the redundant type and explicitly ties the backing variable to the property:</p> <ol> <li>Change the property's type, and the instance variable's type changes.</li> <li>Change its storage qualifier (for instance, make it weak instead of strong or strong instead of weak) and the storage qualifier changes.</li> <li>Remove or rename the property, and the <code>@synthesize</code> will generate a compiler error. You won't end up with stray instance variables.</li> </ol> <p>*-I know one case where it was necessary, relating to splitting functionality across categories in multiple files. And I wouldn't be surprised if Apple fixes this, or even already has.</p>
    singulars
    1. This table or related slice is empty.
    1. POWhen should I use @synthesize explicitly?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USSteven Fisher
    1. USSteven Fisher
    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
    1. COAre you sure? Did you even try? I wrote many custom setters and getters and NEVER synthesized my properties. (And I used your first example, which you said does not work)
      singulars
      1. PO
      1. USMarc
    2. COYes, I'm sure. Code was copy-pasted from a new project. It won't work on recent versions of Xcode **unless** you specify nonatomic on the property.
      singulars
      1. PO
      1. USSteven Fisher
    3. COyes thats true.. but 99% of time your properties are nonatomic. So only in the rare case that your property is atomic and you want a custom getter/setter you actually need to synthesize.
      singulars
      1. PO
      1. USMarc
 

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