How can I declare a #property but prevent its ivar from being created? - objective-c

I have class A, which exposes a way of getting and setting an object of type Foo. In property parlance, I generally declare this in the interface:
#property (nonatomic, strong) Foo * foo;
This (in modern ObjC) generates both the accessors and an ivar, _foo for storage.
If I want to do custom work in the accessors, I can implement one or both of them myself. But what if I not only want to do custom work, I actually don't want the ivar? In other words, I'm doing something else with the Foo object, like handing it back and forth to another internal object that I'm composed with. I don't actually need to keep storage for foo in the instance of A at all.
It seems like I have two choices:
Declare the property, implement both accessors, and simply ignore the fact that the compiler creates storage for _foo, and never use it.
Declare my accessors explicitly: - (Foo *)foo and - (void)setFoo:(Foo *)foo in the interface, like I used to in pre-modern ObjC.
The first seems inelegant at runtime, and the second seems inelegant in the declaration (where I'd probably now have a mix of properties and property-like accessors).
Is there a way to declare a property and have it serve as purely a declaration?

Use the #dynamic keyword in the implementation file. The usual discussion of #dynamic describes it as not creating the accessors at compile time. Not usually mentioned is that is also has the effect of doing nothing to create storage for the property, which is exactly what is desirable in this case.
#implementation A
#dynamic foo;
- (Foo *)foo
{
// get a Foo from somewhere and return it.
}
- (void)setFoo:(Foo *)foo
{
// do something with foo
}
#end
(Note: answered my own question since I discovered this while writing up the question and it seemed interesting and nonobvious.)

If you override both the setter and getter and don't use the variable within the setter and getter, a variable will not be created.
For example, if you have a class for which you want a firstName and lastName property, but perhaps also a setter and getter for a fullName property, if your fullName setter simply parses a string into firstName and lastName and sets these properties to that (and never stores the full string into a fullName variable), and your fullName getter simply returns the concatenated firstName + lastName and never uses a fullName variable, one will never be created.
This is according to Apple's official documentation. Scroll down to "You Can Implement Custom Accessor Methods"

#dynamic is probably the way to go.
However, there are two other ways you can do this as well:
An Unimplemented Category
You can use an un-implemented category to declare a property, but not get the backing storage:
#interface Foo : NSObject
#end
#interface Foo (UnimplementedProperties)
#property (strong) id bar;
#end
#implementation Foo
#end
By not declaring the implementation of the category (#implementation Foo (UnimplementedProperties)), the properties won't be synthesized.
A Protocol
You can declare the properties on a protocol, and then make your class conform to that protocol. This has the same effect as the unimplemented category: the methods are declared, but the properties are not synthesized.
#protocol FooProperties <NSObject>
#property (strong) id bar;
#end
#interface Foo : NSObject <FooProperties>
#end

Related

Objective-C Overriding method in subclass with different parameter type

Here below the definitions of two classes (Foo and Bar) and two respective subclasses (SubFoo and SubBar). Foo is a kind of a dummy class and Bar has a method that takes a Foo instance as a parameter:
#interface Foo
#end
#interface SubFoo : Foo
#end
#interface Bar
- (void)doSthWithFoo:(Foo *)aFoo;
#end
#interface SubBar : Bar
// other methods
#end
Implementations are skipped but consider them being straightforward.
Only then in the implementation of SubBar there is this twist:
#implementation SubBar
- (void)doSthWithFoo:(SubFoo *)aFoo
{
// Do stuff with object of type *SubFoo*
}
// other methods
#end
In the subclass, doSthWithFoo: is overridden and the parameter type is changed to SubFoo – in place of Foo, as in the parent class. This is intentionally done so, as SubBar can only work with SubFoo's so to speak.
This compiles fine, runs fine and does not produce any warnings – kind of surprisingly I must admit. But somehow it doesn't feel very right, even though IMO it's a relatively clean way of doing things..
I am aware that a parameter of type id could be passed instead, but then I'd lose type checking (for Foo) from within Xcode. I am also aware that the same could be accomplished by assigning to id and then to the specific type or by checking and casting – although I haven't tried those options.
Is this a "legitimate" way of doing things? Are there any other alternatives?

do category allow addition of instance variables in its implemenation?

I am working ios6.0 sdk with xcode 4.5.2
Here is following code i used to implement a category
.h
#interface NSObject (busyMode)
#property (nonatomic,assign) BOOL busy;
#end
.m
#implementation NSObject (busyMode)
BOOL _bsy;
-(BOOL)busy{
return _bsy;
}
-(void)setBusy:(BOOL)busy
{
_bsy = busy;
}
#end
as i read along many post, it says that we cannot have instance variables in category. And so above code should not work. But as i tried it out, all was working fine.
Has there been any changes related to category or was it just luck??
As others have pointed out, you didn't add an instance variable, but a global variable which is going to be shared among all of your instances.
Categories cannot add instance variables. However, you can simulate instance variables if you absolutely need them with objc_setAssociatedObject() and objc_getAssociatedObject().
That's because you have defined a single global variable, which isn't an instance variable.
Try and instantiate two instances of this object and you will observe that each instance cannot hold a different value.
You have not added an iVar. You have defined a global variable _bsy and are accessing it in the getter/setter for the property defined by your category.
I have a macro that lets you declare "properties" in categories like this:
#implementation NSObject (AwesomeUtils)
JESynthesize(assign, NSInteger, index, setIndex);
JESynthesize(strong, NSString *, name, setName);
JESynthesize(copy, void(^)(void), completion, setCompletion);
JESynthesize(unsafe_unretained, id, unsafeObject, setUnsafeObject);
JESynthesize(weak, id<UITableViewDelegate>, delegate, setDelegate);
JESynthesize(strong, NSString *, readonlyID, changeReadonlyID);
// …
#end
I say "properties" with quotes because you can use them even without the #property declaration. The macro also works around to support weak.
You can check the implementation here (the header files are at the bottom):
http://nspicks.com/2013/12/15/cleaner-properties-implementation-in-categories/

Property - Implementation of variables in Objective-C

Well ! I got confused about the way of declaring variables & implementing its properties.
The .h File contents
#interface XYZAppDelegate : NSObject <UIApplicationDelegate> {
}
#property (nonatomic, retain) IBOutlet UIWindow *window;
#property (nonatomic, retain) IBOutlet XYZViewController *viewController;
#end
The .m File Contents
#import "XYZAppDelegate.h"
#import "XYZViewController.h"
#implementation XYZAppDelegate
#synthesize window=_window;
#synthesize viewController=_viewController;
My questions/Queries are as follows.
Don't we require to declare variables if we put property ? ( Using property, we can indirectly declare variable - is it like that ? )
What are the additional features other than this ? ( In coding specific )
Why does everybody insist to use _ before each property accessor ? ( Other than security threats ? Has it become coding standard ? Whats the reason behind it? )
You do not have to declare the
variable. It is done automatically,
I believe by #synthesize. One
advantage to declaring it is that the
debugger will automatically list it.
Weigh this against the ugliness of
redundant definition.
Other features: read only properties,
assigned (unretained) values.
The underscore is a convention for
naming member variables that are
differently named than properties and
method variables. Apple's samples
sometimes use this convention and
sometimes do not. I view it as
usually unnecessarily verbose as a
programmer can easily tell the
difference between myVariable and
self.myVariable.
1) Don't we require to declare variables if we put property ? ( Using property, we can indirectly declare variable - is it like that ? )
No. You aren't required to declare variables for the corresponding properties. You are required to use the #synthesize propertyName command which tells the compiler to create those variables for you.
2) Why does everybody insist to use _ before each property accessor ? ( Other than security threats ? Has it become coding standard ? Whats the reason behind it? )
Most people (all?) have been stung by memory management nightmares. Some of these are caused by sloppy/lazy/zero-sleep coding. Using #synthesize propertyName = _propertyName allows the programmer to immediately know that the underscored variable is private to the class, and is unretained. It prevents issues where you specifically allocate or copy an object to store in the property, or accidentally assign an autoreleased object to the ivar.
Consider:
1) An autoreleased object being assigned to an unretained ivar.
#synthesize propertyName;
propertyName = [NSString stringWithFormat:#"I've just made %#", "a boo-boo."];
"propertyName" now references an object that will soon not exist, which will create EXEC_BAD_ACCESS errors down the road (as soon as it's referenced again).
2) A retained object being set to the retained property.
#synthesize propertyName;
self.propertyName = [[NSString alloc] initWithFormat:#"I just created %#", #"a leak"]
Now we've created an NSString object, and set it to the propertyName property, which itself is retaining the variable. Now the object is double retained and won't be properly released.
Both of these issues are easy to combat (even when tired, albeit less so) when you properly name your ivars with an underscore. It's not a fool-proof method, but it makes it considerably easier to manage the retain counts of objects in your head.
(1) No, not with the new 64-bit only features. The variables are declared for you, automatically.
(2) I don't know what you're asking here.
(3) It's just a convention, so that the variable name is different from the accessor name. Makes it clearer which you're dealing with.

Semantic Issue: Property's synthesized getter follows Cocoa naming convention for returning 'owned' objects

I'm currently using the iOS 5 SDK trying to develop my app.
I'm trying to make an NSString a property, and then to synthesize it in the .m file (I have done this before with no issues). Now, I came across this: "Semantic Issue: Property's synthesized getter follows Cocoa naming convention for returning 'owned' objects."
This is my code:
.h
#interface ViewController : UIViewController {
NSString *newTitle;
}
#property (strong, nonatomic) NSString *newTitle;
.m
#synthesize newTitle;
Does anyone have a clue how I could fix this?
Thanks!!
My guess is that the compiler version you’re using follows the memory management rules for declared properties, too — more specifically, for declared properties’ accessors:
You take ownership of an object if you create it using a method whose name begins with “alloc”, “new”, “copy”, or “mutableCopy”.
A property named newTitle, when synthesised, yields a method called -newTitle, hence the warning/error. -newTitle is supposed to be a getter method for the newTitle property, however naming conventions state that a method whose name begins with new returns an object that’s owned by the caller, which is not the case of getter methods.
You can solve this by:
Renaming that property:
#property (strong, nonatomic) NSString *theNewTitle;
Keeping the property name and specifying a getter name that doesn’t begin with one of the special method name prefixes:
#property (strong, nonatomic, getter=theNewTitle) NSString *newTitle;
Keeping both the property name and the getter name, and telling the compiler that, even though the getter name starts with new, it belongs to the none method family as opposed to the new method family:
#ifndef __has_attribute
#define __has_attribute(x) 0 // Compatibility with non-clang compilers
#endif
#if __has_attribute(objc_method_family)
#define BV_OBJC_METHOD_FAMILY_NONE __attribute__((objc_method_family(none)))
#else
#define BV_OBJC_METHOD_FAMILY_NONE
#endif
#interface ViewController : UIViewController
#property (strong, nonatomic) NSString *newTitle;
- (NSString *)newTitle BV_OBJC_METHOD_FAMILY_NONE;
#end
Note that even though this solution allows you to keep newTitle as both the property name and the getter name, having a method called -newTitle that doesn’t return an object owned by the caller can be confusing for other people reading your code.
For the record, Apple have published Transitioning to ARC Release Notes, in which they state:
You cannot give a property a name that begins with new or copy.
They’ve already been notified that their statement is not quite accurate: the culprit is the getter method name, not the property name.
Edit 17 Jan 2015: I’ve just noticed a recent commit to Clang that suggests option 3 above (using objc_method_family(none)), including a fix-it, for the general case where a property name matches one of the special method family prefixes. Xcode will likely incorporate this change eventually.
Unacceptable Object Names
newButton
copyLabel
allocTitle
Acceptable Object Names
neueButton
mCopyLabel
_allocTitle
#arc #auto-synthesized #xcode-4.6.1
** EDIT **
Apparently you can't use mutableCopy either.
The name of the member starting with new is what triggers the warning. Change the name to editedTitle and the warning will go away. I was unable to find documentation confirming this but through testing was able to determine that member variables that begin with 'new' aggravate the compiler.
ARC does not allow to use "New...." in property name. but you can use "newTitle" by changing getter name.
#property (nonatomic, strong, getter=theNewTitle) NSString *newTitle;
It doesn't look like what Bavarious was suggesting was what you wanted to do. All you want to do is declare an instance variable NewTitle and then synthesize the property. We used to have to declare the instance variable and property. No more.
Now, I believe the right way of doing this is the following:
.h
#interface ViewController : UIViewController
#property (nonatomic, strong) NSString *newTitle;
.m
#synthesize newTitle = _newTitle; // Use instance variable _newTitle for storage
The instance variable for the property newTitle is synthesized. You don't want your instance variable to be the same as your property - too easy to make mistakes.
See Example: Declaring Properties and Synthesizing Accessors
In CoreData if you use "new..." in attribute (compile normally) it will crash randomly with a "bad access" exception.
There is no crash log and the line shown with the "All Exceptions Breakpoint" will not help you at all.
Writing a setter manually with the name same as the property's removed this warning.
NS_RETURNS_NOT_RETAINED is used to solve the naming problem.
#property (nonatomic, copy) NSString *newTitle NS_RETURNS_NOT_RETAINED;
We can find its definition as follows:
#define NS_RETURNS_NOT_RETAINED __attribute__((ns_returns_not_retained))
The 'ns_returns_not_retained' attribute is the complement of 'ns_returns_retained'. Where a function or method may appear to obey the Cocoa conventions and return a retained Cocoa object, this attribute can be used to indicate that the object reference returned should not be considered as an "owning" reference being returned to the caller. The Foundation framework defines a macro NS_RETURNS_NOT_RETAINED that is functionally equivalent to the one shown below.
Besides the issue that you should/can't use "new" in front of you property names, let say one more thing: Try to avoid "new" in front of names in general. "New" is dependent on time. Currently it is new for you, but some time later you maybe want to implement something new again. So using "new" in names is always bad. Try to think this way: In the programming world, "new" is always creating something: a new instance of something.
In your case when you want to assign a different title then the current name your property titleReplacement.
One more thing: Try to name functions and methods with the verb first, like setSomething or getSomething.
But in properties try to name the object first, like heightMinimum, heightMaximum, etc. -> when you use your inspector when you are coding, you always looking for objects. Try it out. ;-)
try this:-
#property (nonatomic,retain) NSString *newTitle;

How Apple manage #private var and #properties?

I take for example the UIButton interface.
Here the first rows of #private definition :
#private
CFMutableDictionaryRef _contentLookup;
UIEdgeInsets _contentEdgeInsets;
UIEdgeInsets _titleEdgeInsets;
And here 2 of these ivar, that are defined as properties:
#property(nonatomic) UIEdgeInsets contentEdgeInsets;
#property(nonatomic) UIEdgeInsetstitleEdgeInsets;
However these 2 properties are not defined on the ivars i found in private method (which have suffix _).
I'm not sure to understand how could be implemented setter and getter for these 2 properties to refer to the private ivars.
And a second question... i used to create properties for ivar, thus, if i have an ivar FOO i can create a #property for FOO. Is it a normal behavior create property for a non existing ivar ? (in this case contentEdgeInsets is not an attribute for this class... on the contrary _contentEdgeInset is defined in #interface and this's a valid ivar). Ok what i missed with this argument ?
When you #synthesize these properties you do so like
#synthesize contentEdgeInsets = _contentEdgeInsets;
^property name ^iVar name
Check out the Property Implementation Directives section in the documentation.
By default, a property will use the ivar whose name is the same as that of the property, but it's also possible to specify an ivar of a different name. Do this in your #synthesize statement in the class implementation.
In the modern runtime, used pretty much everywhere at this point, you don't actually have to declare the ivar at all -- if you synthesize accessors for a property and there's no matching ivar, the runtime will provide one.
Finally, properties with #dynamic rather than #synthesized accessors don't necessarily need an ivar at all -- you're providing the accessors in this case, so you're free to derive the value of the property however you like.