Does UIViewController's presentModalViewController:animated: retain the modal controller?

The memory management rules of Objective-C define the behaviour, so it doesn't need to expressly document that it retains the modal view controller. If an object needs to keep a passed object around after the method has finished executing, it will retain the object unless otherwise specified.

The memory management rules of Objective-C define the behaviour, so it doesn't need to expressly document that it retains the modal view controller. If an object needs to keep a passed object around after the method has finished executing, it will retain the object unless otherwise specified. So in this case, you should just pass the view controller to presentModalViewController:animated: and then release it (or use autorelease).

This applies everywhere in Objective-C. If an object takes another object as method input, you never have to retain that object on its behalf. As requested in the comments, if you read Apple's documentation on memory management, then you'll find the section on Weak References, which states: Important: In Cocoa, references to table data sources, outline view items, notification observers, and delegates are all considered weak (for example, an NSTableView object does not retain its data source and the NSApplication object does not retain its delegate).

The documentation only describes exceptions to this convention. This actually states that this is a convention in itself and that exceptions will be stated in the documentation, however, going to the documentation for NSTableView and looking at the setDataSource: method, we see: Discussion In a managed memory environment, the receiver maintains a weak reference to the data source (that is, it does not retain the data source, see Communicating With Objects). After setting the data source, this method invokes tile.

This method raises an NSInternalInconsistencyException if anObject doesn’t respond to either numberOfRowsInTableView: or tableView:objectValueForTableColumn:row:.

They take objects as method inputs, keep them around, and you do have to retain the object on its behalf. If you could show me where, in the docs, it states that all weak ref storing methods will explicitly state the lack of retain, then I would be happy. – Matt Wilding Dec 18 '10 at 8:55 Your first citation seems to set up a specific set of instances where weak-refs are default, and strong refs will be noted as exceptions.

It does not tell me that strong refs are default, and weak-refs will be noted as exceptions, which is what you seem to imply with your statement: "If an object needs to keep a passed object around after the method has finished executing, it will retain the object unless otherwise specified. " – Matt Wilding Dec 18 '10 at 9:38 Also, I realize I'm being extremely nit-picky here. I appreciate your thoughts and I agree with you that it does make total sense as far as convention is concerned.

– Matt Wilding Dec 18 '10 at 9:40.

Hmm good question! I'm not totally sure about your assumptions. The property in question is defined in the docs as: @property(nonatomic, readonly) UIViewController *modalViewController As you point out, it doesn't specify how it is stored.

This document: developer.apple.com/library/mac/#documen... in fact, states that if retain/assign/copy is not specified, that assign is the default behavior. I've also read d11wtq's reply, but am not sure I totally agree. I agree about the conventions about obj-c memory management, but there are many cases where framework methods don't retain properties (think weak references, delegates, etc).

I hope somebody can confirm your assumptions.

I agree with you on the weak references point. I could see this theoretically going both ways, which is why I would sleep better with solid verdict. – Matt Wilding Dec 18 '10 at 8:49 ummm, care to comment why you downvoted?

– darren Dec 18 '10 at 8:49 If an object does not retain an object, but needs it to stay around, the behaviour should be documented as such. Obviously for third-party frameworks I can't guarantee this since it's up to the developers of the framework to document it, but within the scope of apple products, exceptions to the rule 100% should be documented. – d11wtq Dec 18 '10 at 9:09 1 That document you link to is talking about declared properties and is not related to this question.

The user is asking about presentModalViewController:animated:. That is just a method... not a declared property (by the way, just in case you think it was me who downvoted, it wasn't ;)) The retain/assign stuff on properties only applies to setters. It does nothing for readonly properties.

– d11wtq Dec 18 '10 at 9:13.

Sure it's documented. And by the way, I doesn't know the other way :D I use the alloc-present-release method since I started iOS programming 1.5 years ago You can find the sample code if you launch XCode and create a "Utility Application". In the (Apple provided) code should be: FlipsideViewController *controller = FlipsideViewController alloc initWithNibName:@"FlipsideView" bundle:nil; controller.

Delegate = self; controller. ModalTransitionStyle = UIModalTransitionStyleFlipHorizontal; self presentModalViewController:controller animated:YES; controller release.

Well, that is good to know that Apple's code does it. – Matt Wilding Dec 18 '10 at 20:22.

I guess iPortable's answer gives you what you want - a peace in your mind when you are releasing the view controller in that way. By the way, a part of the reasons why printing out retainCount is not a good debugging strategy is because where you put NSLog or breakpoint may not be the right place to look at the retain count. Some retaining or releasing may follow AFTER you check its retain count caused by the event you are interested in.So if you really want to know what the retain count would be since an event, just override -(id) release and -(void) release method and print logs there, and count yourself.

Of course, you must call superclass's retain/release at the end of your methods. In this way, for example, you can get a very clear answer to your original question.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.