If you use the synthesize directive to tell the compiler to create the accessor methods see Property Implementation Directives , the code it generates matches the specification given by the keywords. If you implement the accessor methods yourself, you should ensure that it matches the specification for example, if you specify copy you must make sure that you do copy the input value in the setter method.
The following attributes allow you to specify custom names instead. Specifies the name of the get accessor for the property. Specifies the name of the set accessor for the property.
Typically you should specify accessor method names that are key-value coding compliant see Key-Value Coding Programming Guide —a common reason for using the getter decorator is to adhere to the is PropertyName convention for Boolean values. These attributes specify whether or not a property has an associated set accessor.
They are mutually exclusive. Both a getter and setter method are required in the implementation block. If you use the synthesize directive in the implementation block, the getter and setter methods are synthesized. If you specify readonly , only a getter method is required in the implementation block. If you use the synthesize directive in the implementation block, only the getter method is synthesized.
Moreover, if you attempt to assign a value using the dot syntax, you get a compiler error. If the destination object is deallocated, the property value is automatically set to nil. The previous value is sent a release message. The copy is made by invoking the copy method. This attribute is valid only for object types, which must implement the NSCopying protocol.
Specifies that retain should be invoked on the object upon assignment. In OS X v Properties are atomic by default so that synthesized accessors provide robust access to properties in a multithreaded environment—that is, the value returned from the getter or set via the setter is always fully retrieved or set regardless of what other threads are executing concurrently. If you specify strong , copy , or retain and do not specify nonatomic , then in a reference-counted environment, a synthesized get accessor for an object property uses a lock and retains and autoreleases the returned value—the implementation will be similar to the following:.
If you specify nonatomic , a synthesized accessor for an object property simply returns the value directly. Properties support the full range of C-style decorators. IBOutlet is not, though, a formal part of the list of attributes. For more about declaring outlet properties, see Nib Files. If a group of objects is connected by a circle of strong relationships, they keep each other alive even if there are no strong references from outside the group.
In order for a generic table view class to be useful in multiple situations, it delegates some decisions to external objects. This means it relies on another object to decide what content it displays, or what to do if the user interacts with a specific entry in the table view. A common scenario is that the table view has a reference to its delegate and the delegate has a reference back to the table view, as shown in Figure A problem occurs if the other objects give up their strong relationships to the table view and delegate, as shown in Figure Even though there is no need for the objects to be kept in memory—there are no strong relationships to the table view or delegate other than the relationships between the two objects—the two remaining strong relationships keep the two objects alive.
This is known as a strong reference cycle. The way to solve this problem is to substitute one of the strong references for a weak reference. A weak reference does not imply ownership or responsibility between two objects, and does not keep an object alive. If the table view is modified to use a weak relationship to its delegate which is how UITableView and NSTableView solve this problem , the initial object graph now looks like Figure When the other objects in the graph give up their strong relationships to the table view and delegate this time, there are no strong references left to the delegate object, as shown in Figure This means that the delegate object will be deallocated, thereby releasing the strong reference on the table view, as shown in Figure Once the delegate is deallocated, there are no longer any strong references to the table view, so it too is deallocated.
To declare a weak reference, add an attribute to the property, like this:. Local variables and non-property instance variables also maintain strong references to objects by default. This means that the following code will work exactly as you expect:.
In this example, the local variable originalDate maintains a strong reference to the initial lastModificationDate object. When the lastModificationDate property is changed, the property no longer keeps a strong reference to the original date, but that date is still kept alive by the originalDate strong variable.
To avoid a dangerous dangling pointer to the memory originally occupied by the now deallocated object, a weak reference is automatically set to nil when its object is deallocated. When self. If there are no other strong references to it, the original date will be deallocated and originalDate set to nil. In this example, the newly allocated object has no strong references to it, so it is immediately deallocated and someObject is set to nil.
In situations like this, you might want to cache the weak property in a strong variable to ensure that it is kept in memory as long as you need to use it:. Instead, you need to declare a strong local variable to cache the value, like this:. In this example, the strong reference is created in line 1, meaning that the object is guaranteed to be alive for the test and method call. In line 5, cachedObject is set to nil , thereby giving up the strong reference.
If the original object has no other strong references to it at this point, it will be deallocated and someWeakProperty will be set to nil. If you need to use a weak reference to one of these classes, you must use an unsafe reference.
In some circumstances, an object may wish to keep its own copy of any objects that are set for its properties. Two NSString properties are declared, which both maintain implicit strong references to their objects. You might choose that the badge view should maintain its own copies of any strings set for its firstName and lastName properties, so that it effectively captures the strings at the time that the properties are set. By adding a copy attribute to the two property declarations:.
Even if a mutable string is set and subsequently changed, the badge view captures whatever value it has at the time it is set. For example:. The copy attribute means that the property will use a strong reference, because it must hold on to the new object it creates. Declare and implement a new designated initializer used to create an XYZPerson using a specified first name, last name and date of birth, along with a suitable class factory method.
Change the NSString property declarations by adding the copy attribute and test again. This keyword simply creates a getter and a setter method for that property. For instance, if you simply create a property named firstName , the compiler will take the following actions on your behalf:. This rule applies similarly to any other property name. Triggers the following synthesize for you in your implementation file without you having to touch it:. Under Automatic Reference Counting, it also takes care of deallocating your properties for you.
The example code prints the first name of newPerson twice, first using its firstName property and then by calling the firstName getter method on that object. Both will point to the same method, which synthesize created for us in the Person. In an older version of the Objective-C runtime, for property to work, we also had to define an instance variable.
An instance variable is a variable whose memory management is done by the programmer herself. Instance variables are also not exposed to classes outside the scope of the class that defines them i. We simply define the property and the LLVM compiler defines the ivar for us. For instance, in GCC 4. If you want to fiddle around with setter and getter methods, you are free to do so. Even if you have used synthesize to allow the compiler to generate the setter and getter methods of a property for you, you can still go ahead and override those methods.
For instance, in this example, I change the setFirstName: setter method of the firstName property of the Person :.
0コメント