1

I have read a few questions on the differences between iVars and Properties like these: Why would you use an ivar?
ios interface iVar vs Property

What I would like to know is... If I am creating a BOOL that needs to be accessed in multiple methods in a UIViewController (for example) what is the best way to create these?

At present I create proprties. This works fine and as expected. But as I read/learn more it appears that creating an iVar would be better for performance.

Like:

@interface ViewController : UIViewController{
BOOL myBool;
}

Would this be better for performance, and can multiple methods access this iVar if I set the value to YES in one, can I check the value in the other - as I can with property approach?

Community
  • 1
  • 1
StuartM
  • 6,743
  • 18
  • 84
  • 160

4 Answers4

4

can multiple methods access this iVar if I set the value to YES in one, can I check the value in the other

Of course you can, even if you set the value to NO. It is an instance variable and thus shared between all methods of one instance.

Would this be better for performance

No, unless you access the property very, very often, like 2^20 times per frame. Have a look at this Big Nerd Ranch post about iVar vs property performance. Usually the performance gain is not worth the loss in clarity.

Sebastian
  • 7,670
  • 5
  • 38
  • 50
  • Accepting for the clarity in answering all parts of the question and linking to the further information on performance. – StuartM Oct 18 '13 at 14:25
3

The "better performance" is something that would be very rare to affect an app. Write code for clarity, then if there are performance issues profile and fix the code that is actually causing the problem.

zaph
  • 111,848
  • 21
  • 189
  • 228
1

For your purpose an ivar would be equivalent to using a property. Performance-wise the ivar is slightly better because you access it directly, whereas with a property you invoke a method (getter or setter) that was generated by the compiler in the background.

I wouldn't worry about performance, though. Typically the difference will be negligible. Unless you have some really special need, I would always use properties because it usually results in clearer code. It's also a good habit to have getter and setter methods - even if they are generated by the compiler for you - because they encapsulate the data of your class.

herzbube
  • 13,158
  • 9
  • 45
  • 87
1

I usually go with this:

@interface MyVC : UIViewController
@property (nonatomic, getter=isDoingSomething) BOOL doingSomething;
@end

I also explicitly name the getter in the property declaration which gives you access to the property in a way that is easy to read. (Setting the property is done by sending setDoingSomething: and the getter is [theVC isDoingSomething])

Nonatomic properties are recommended on iOS. In regards to what I had backwards before, the default atomic behavior adds locks to the synthesized code, and is not recommended for performance reasons. Any issues with threads would have to be handled in your own setters (which you would have to do anyway when using an ivar). Personally I haven't ran into any issues with this.

I won't repeat other answers about performance but besides pointing out the fact that tapping a button sends way more messages than accessing a property, so the performance penalty is trivial.

Myron Slaw
  • 886
  • 9
  • 21
  • 1
    You've got them backwards. *Atomic* avoids partial values and truncated object lifetimes when dealing with threads. *Nonatomic* doesn't attempt to protect from those issues. – Catfish_Man Oct 18 '13 at 01:09
  • You are correct and I fixed my answer. Also since the question is about creating a BOOL property, and BOOL is not an object, it's as simple as, "Do I want the locks to be added (atomic) or not (nonatomic) and do it myself if needed. Am I correct? – Myron Slaw Oct 18 '13 at 01:44
  • 1
    In the case of a single Boolean, no locking is necessary for atomicity on most architectures. The runtime will do the right thing and not lock unnecessarily though :) – Catfish_Man Oct 18 '13 at 02:30