1

I have a problem in one of my VCs called ArticleViewController. The dealloc method is never called, and when the view is opened and closed three times, there are three VCs alive.

I read here (great source when you have a retain cycle in your ViewController!) the following:

If you use

someObj.delegate = self;

inside the view controller, check the delegate property on someObj is weak.

@property (nonatomic, weak) id delegate;

One of the snippets in my VC is:

PopViewController *pop=[[PopViewController alloc] initWithNibName:@"PopViewController" bundle:nil];
pop.delegate = self;

So I check in PopViewController.h if the property is weak.

@property (nonatomic, assign) id <PopViewControllerDelegate> delegate;

Since strong is the default, and there is no explicit weak here, would this cause my retain cycle? I am bit in doubt, because I see the same thing in the header file of e.g. UIPopoverController.h, which is in the UIKit.

@property (nonatomic, assign) id <UIPopoverControllerDelegate> delegate;
physicalattraction
  • 6,485
  • 10
  • 63
  • 122
  • The `assign` should be changed to `weak` but the `assign` will not cause your reference cycle since `assign` doesn't increase the reference count. You must have something else causing the reference cycle. – rmaddy Jun 18 '15 at 14:55

2 Answers2

1

You should change it to weak. assign is default for primitive types and should be used by primitive types. id is an object, so it should be either weak or strong - in this case weak, because you should not increase the reference counter.

You can read more about strong/weak/assign here, great explanation as far as I've noticed: SOF question about ARC.

Glad to see it's an important case for you as many people even not so new in Obj-C just 'skip' the problem and run into memory issues later.

-- edit --

Maybe you have any block inside and you're keeping a strong reference to self inside? Any dispatch or anything? Maybe you have property on another controller to this one and that's why it's still living?

Community
  • 1
  • 1
Nat
  • 12,032
  • 9
  • 56
  • 103
  • You don't actually answer the question: *"Since strong is the default, and there is no explicit weak here, would this cause my retain cycle?"* – rmaddy Jun 18 '15 at 14:56
  • If `assign` does not not increase reference count and `strong` does, then how could (according to the link in the answer) both `strong` and `assign` be the default? Are they not mutually exclusive? – physicalattraction Jun 18 '15 at 15:00
  • 1
    @physicalattraction `strong` is default for objects (`id` is an object), `assign` is default for primitive types (`int` etc). – Nat Jun 18 '15 at 15:01
  • @rmaddy You're right, mea culpa. When I got to the part where id is set to be assign, I've just skipped my eyes through rest of the question and typed the answer, didn't even see that line. Well, glad to see you've referenced the question in your comment. Still, I hope my answer is helpful here anyway as it refers to the bases of the problem. – Nat Jun 18 '15 at 15:10
1

From the Transitioning to ARC Release Notes:

assign is nearly the same thing as weak in the sense that it will not increment the retain count of the object, so it cannot be the source of your retain cycle.

The difference with weak is that when the pointed object is deallocated, a weak pointer will nil itself, but an assign (or __unsafe_unretained) pointer will still point to the free'd memory, resulting in a crash next time you try to dereference it.

tl;dr: you can keep assign, it is not the source of your memory issue, but using weak is safer and will produce less crashes (because messaging nil is a no-op).

Guillaume Algis
  • 10,705
  • 6
  • 44
  • 72