Retaining cycle with passing objects

Question

I am interested in retaining cycles. Let assume we have two views, A and his subview B.

I know that if B has a (custom) delegate defined as

class B: UIView {

    var delegate : CustomDelegate?
}

and I set inside A :

b.delegate = self

This create retain cycle, because B has strong reference to A and A has strong reference to be, so neither could be freed.

Question :

What if I have object inside A and I want to pass it to the B object.

class B: UIView {

    var object : SomeObject?
}

and inside A :

b.object = self.object

Is this a retaining cycles too? I can't figure this out.

When object (in A) is created it's reference is 1. When it is passed to the B it's reference is 2. But when A try to deallocate itself : When deallocate object in A it reduce reference to 1 and when he try to deallocate B the object reference should go to 0. Is this mean that there is no retaining cycles? Or did B holds indirect reference to A trough object?

Second question :

What could I lose if all object inside B would be weak references? Or better witch object need to be weak?

Your code makes no sense. How can UIView A say `self.object`? It has no `object` property. And what is a SomeObject? — matt, Mar 22 '17 at 16:49
"What could I lose if all object inside B would be weak references? Or better witch object need to be weak?" Too broad, or circular. — matt, Mar 22 '17 at 16:50
Matt, the code inside A is only a illustration, of course A should have variable object, and A should add B as subview,... but I think this is applied by the case. With all objects inside B, I thought about object that will be set inside A, but you answered me implicitly. — Marko Zadravec, Mar 22 '17 at 17:28
In general you might want to read my explanation of what memory management _is_, starting here: http://www.apeth.com/iOSBook/ch12.html#_principles_of_cocoa_memory_management — matt, Mar 22 '17 at 17:46
One additional question: in my question http://stackoverflow.com/questions/21987067/using-weak-self-in-dispatch-async-function the answer was that (in Edit section) inside block setting self.users will cause retaining cycle. But is't this similar as our A,B objects. ViewController is an A ant have object user and another object block (witch is B). B (block) holds reference to users and View controller holds reference to users, but block doesn't hold reference to ViewController,... — Marko Zadravec, Mar 22 '17 at 18:35
There is a highly specialized situation having to do with the nature of closures (blocks). Setting a property to `self.object` merely passes a reference to that object. Mentioning `self.users` inside a closure captures `self`, and if `self` then retains that closure, you have a retain cycle. See my explanation: http://www.apeth.com/swiftBook/ch05.html#SECweakSelf — matt, Mar 22 '17 at 18:56

matt · Accepted Answer · 2017-03-22T17:02:08.733

I assume your first (and only real) question is intended to imply something like this:

class A : UIView {
    var object : NSObject
}
class B : UIView {
    var object : NSObject
}

... and then we posit that we have an A and a B where the B is a subview of A. So then the A might say:

(self.subviews[0] as! B).object = self.object // or similar

... and you want to know whether there's a retain cycle involved here. No, not in the general case. There are two objects, an A and a B, and they each have a strong reference to the same third object, i.e. something that is neither this A nor this B. There's nothing wrong with that, and indeed it could be crucial that the A and the B both retain the third object. We might question the legitimacy of A telling B what its object should be, and we might legitimately be disturbed by the possibility that the A could mutate this third object behind the B's back (or vice versa); but from a memory management point of view, nothing of interest has happened.

What could I lose if all object inside B would be weak references

You could lose everything. Remember, normal (strong) references are a way of keeping the referenced object alive (retain); that is what memory management of properties is all about. Assigning to a weak reference, on the other hand, doesn't do that, and thus can cause the assigned object to disappear immediately, if nothing else is retaining it. Weak references are only for cases where the lifetime of the referenced object is correctly and entirely determined elsewhere (as in, a superview determines the lifetime of its subviews).

Retaining cycle with passing objects

1 Answers1