0

I am have read up some tutorials on ARC and am still left a bit confused on properties declarations. I wrote most most my code using the following pattern:

@property (readwrite, nonatomic) PlayerData* playerData;
@property (readwrite, nonatomic) MusicLayer* musicLayer;
@property (readwrite, nonatomic) bool isPowerUpAvailable;

Now that I finally started to deal with memory leaks XCode suggested me that in some bits of code I should have added the "retain" keyword in the property declaration.

Using ARC I thought I shouldn't "Bother" about retain counts anymore. Is there some concept I am not getting or missing? Any tutorial references or explanation would be greatly appreciated.

mm24
  • 9,280
  • 12
  • 75
  • 170

2 Answers2

4

ARC is will retain object based on the property declaration, you should use strong for properties that need to be retained and weak for properties that do not need to be retained.

weak properties are also nilled when the object is deallocated.

The compiler will always assume that properties are readwrite so there is no need to declare then this way. 

@property (strong, nonatomic) PlayerData* playerData;
@property (strong, nonatomic) MusicLayer* musicLayer;
// Need use assign since strong is for objects only.
@property (assign, nonatomic) bool isPowerUpAvailable;
rckoenes
  • 69,092
  • 8
  • 134
  • 166
  • Thanks, can accept the answer only in 5 minutes due to SO. Was wondering.. what are the cases in which I would want a weak reference? Am I right in saying that for "most" of the cases a strong reference is preferred? – mm24 Mar 29 '13 at 11:58
  • Yes in most cases `strong` will do, but like for a `delegate` property `weak` will be better, since the delegate could also be retaining the object for which it is the delegate. – rckoenes Mar 29 '13 at 12:02
  • So for instance, if I create an object (say A) in a class and then pass this object in the constructor of B, then I should declare the "receiving" pointer in B as delagate property? – mm24 Mar 29 '13 at 13:06
  • 1
    No that is just a normal property, a delegate is when an object call methods on an other class, like `UITableView` does when a user selects a row. Since mostly these calles delegate and owner are the some `weak` is used. – rckoenes Mar 29 '13 at 13:13
  • Thanks. Kind of got it. In my case I got a main scene class that handles the "logic" of the game. Then I got some "child" class that is added to the main scene class where I load the level specific data (sprites). From the logic class init I schedule a call to an "update" method and at each update I call the "move" method in the "child" class. The sprites are added to the main class but in the child class I keep an array with references to the sprites in order to allow the "move" method to actually move them. Does this sound dangerous :)? – mm24 Mar 29 '13 at 13:19
  • In other words, shoudl I rethink everything or given it doesn't seem to leak that bit of code keep it and "save" development time? – mm24 Mar 29 '13 at 13:20
  • 1
    If you are not leaking (use the profiler and analyzer) you should be fine. – rckoenes Mar 29 '13 at 13:23
  • Don't forget `copy` for objects of class clusters with mutable immutable pairs most of the time. – Abizern Jun 30 '13 at 10:31
0

If you prefer continue to use your code, you can exclude ARC only on the specific file .m you want:

Go to Targets > Build Phases > Compile Sources and select your .m file double click on right column of the selection and add -fno-objc-arc so you are exclude ARC only a selected file.

Or if you want to convert all application to new code with ARC, after make a Backup of you project, go to:

Edit > Refactor > Convert to Objective-C ARC and after this do the same but click on Convert to modern Objective-C Sintax

here the screen:

enter image description here Pay attention not always working before to try duplicate your project!

Hope this help you

BlackSheep
  • 1,087
  • 12
  • 29