How do you know that pushViewController retains the pushed object?

The answers here all say that pushViewController retains the given viewController but they don't refer to a document that states this.

Question is how do they know that pushViewController will retain the given view controller? Can we assume that this convention is adhered to by all other classes that take your NSObject* derived object pointer?

Edit:

I need a stronger argument/proof than what the currently presented answers propose. For example the documentation about UIView::addSubview clearly states 'This v开发者_运维百科iew is retained by the receiver'. Alternatively, if you intend to show that the received controller is retained by implication because the UINavigationController has the same semantics as a collection class, then show that it does, by showing that it uses one of the collection classes internally or referencing some documentation that states this. The documentation for pushViewController says that the given view controller is placed on the 'navigation stack' but nowhere does it say what class this stack is. In fact, looking at the definition in the header file of the UINavigationController, it looks like it's not using a stack, but using NSMutableArray. If you've done a math's degree and written proofs then you'll understand the sort of intellectual rigor I'm looking for.

Because collections always own their items, and parents always own their children.

In a sense, the navigation controller is operating like a type of collection - a stack.

If the controller up and disappeared on the navigation controller - that would be a big problem.

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html#//apple_ref/doc/uid/TP40004447-SW1

When you add an object to a collection (such as an array, dictionary, or set), the collection takes ownership of it. The collection will relinquish ownership when the object is removed from the collection or when the collection is itself released.

you should try this

id temp = [self.navigationController.viewControllers objectAtIndex:1];
[self.navigationController popToViewController:temp animated:YES];

you'll be navigated to any other previous ViewController that are available in the stack.

Apple's documentation has never been the most rigorous. What do you get with [NSString stringWithString:nil]? [NSArray arrayWithArray:nil]? [NSURL URLWithString:nil]?

(Answers: An exception, an empty array, and either an exception or nil depending on OS version.)

At the end of the day, it doesn't matter that much what documentation says. Objective-C is largely about convention, and if you understand the conventions, you'll generally get it right. It goes wrong when there are edge cases the documentation didn't mention and you didn't test, or the documentation is wrong (AVCapture on iPhone 3G does not support 420v) or Apple changes what happens for edge cases (with NSURL above, it means that older OS versions crashed where newer ones were fine), or someone introduces a bug (e.g. AVCapture at 640x480 420v hangs on 4.1/3GS, but only if you set it - 420v is the default, and if you don't touch it it works fine!).

And when it goes wrong, pointing fingers at the documentation won't save you. Even if it's not your fault, it's still your problem: Your app crashes, and you owe it to your users to fix it (unless Apple prevents you from doing so, which happens too).

Testing beats documentation.

show that it does, by showing that it uses one of the collection classes internally or referencing some documentation that states this.

From the View Controller Programming Guide:

The navigation stack is a last-in, first-out collection of custom view controller objects that is managed by the navigation controller.