Asi Givati Asi Givati - 21 days ago 10
iOS Question

should i release strong properties by myself?

I know but not exactly how all the arc works.
I know when to use weak properties to prevent memory leaks.
But I want to understand something else.
If I have

UIViewController
with strong custom view inside him like this:
@property (nonatomic) UIView myView;
(the default is strong if we not specify anything).
If this view was weak, I know that don't need to care about releasing it, but what about strong?
Is it stay alive after my ViewController didDisappear / dealloc when it strong?
1. Should I set this view to nil in the viewWillDisappear?
2. Why when I create a weak property it's not exist anymore after I call its "init" method?

CRD CRD
Answer

Let's see if we can help:

If I have UIViewController with strong custom view inside him like this: @property (nonatomic) UIView myView; (the default is strong if we not specify anything). If this view was weak, I know that don't need to care about releasing it, but what about strong? Is it stay alive after my ViewController didDisappear / dealloc when it strong?

Don't think about reference counts or releasing, ARC really turns things around. The strong, weak, etc. attributes are associated with the variable, and you can understand this by taking a variable-centric view in which the variables are the actors - the entities controlling the lifetime of referenced objects.

Taking this view when a reference is stored into a variable which has the strong attribute then the variable informs ARC that it requires the referenced object to stay around.

Remove that reference from the variable; e.g. by overwriting it with another reference or with nil; then the variable tells ARC it no longer requires the referenced object to stay around.

ARC itself simply keeps an object around as long as there is at least one variable which has told ARC that the object is required and has not yet withdrawn that requirement.

Your question is what happens when ARC removes an object which has instance variables which have the strong attribute. Taking the variable-centric view the question becomes: what happens when a variable itself is destroyed?

The answer is that the last act of a variable which has the strong attribute. and has a reference stored in it, is to tell ARC that the variable no longer requires the referenced object to be kept around.

  1. Should I set this view to nil in the viewWillDisappear?

You only need to set a variable which has the strong attribute to nil if the variable itself will continue to exist long after you have need of the object that is referenced by the reference stored in the variable.

E.g. if you have a long living object which during its lifetime stores a reference to a large object for a short period in one of its instance variables then setting that variable to nil at other times makes sense.

  1. Why when I create a weak property it's not exist anymore after I call its "init" method?

I assume here that you mean "create an object and store a reference to it in a weak property".

Staying with the variable-centric view a variable which has the weak attribute does not tell ARC to keep objects around, as one with the strong attribute does, rather it monitors the referenced object and when it goes away it sets itself to nil.

If you create an object it will only be kept around by ARC as long as there is a reference to it stored in a variable which has the strong attribute. If all you do with the reference is store it in a variable which has the weak attribute there is no requirement for ARC to keep the object around.


Treating the variables as the actors above is of course an analogy, variables themselves are not active entities. What in reality happens is that during compilation the compiler inserts instructions which do the actions ascribed to variables above. The result is the same.


TL;DR: strong & weak are attributes associated with variables not with references. Consider the lifetime of the variables and what is stored in them to determine whether any objects are kept around or removed.

HTH