mikeash.com pyblog/friday-qa-2012-04-13-nib-memory-management.html comments

haipret - 2015-07-10 08:18:51

Fri, 10 Jul 2015 08:18:51 GMT

Why objects in storyboard that are attached to scene of view controller are deinit with view controller deinit even if they are not view controller's view subviews and are not outlet-ed to the view controller?

Jul - 2013-06-13 16:57:39

Thu, 13 Jun 2013 16:57:39 GMT

For iOS using ARC, if I set the property as strong for 1 of my subviews, and do not set it to nil in -didReceiveMemoryWarning (or viewDidUnload when it wasn't deprecated), will it leak or cause some kinds of problem? If yes, please explain. If not, then is there any downside for using @property (strong) for those outlets?

Ari Braginsky - 2012-10-18 17:04:06

Thu, 18 Oct 2012 17:04:06 GMT

Note: with iOS 6 viewDidUnload is now deprecated. I guess if you're using strong for IBOutlet properties and are concerned with low memory conditions, you can still set them to nil in -didReceiveMemoryWarning.

hankbao - 2012-06-19 05:48:06

Tue, 19 Jun 2012 05:48:06 GMT

There is actually a special scene in iOS.

If you got some top-level objects in your MainNib, they are not autoreleased and will remian in memory except you release them explicitly.

In some circumstance, this may cause a leak.

Jorge - 2012-05-04 19:57:39

Fri, 04 May 2012 19:57:39 GMT

A small comment i would add to the article would be something like...

'When the NIB gets loaded, 'viewDidLoad' method gets called... and... if for whatever reason you need to force the ViewController to load a nib file during the init... the common hack is to simply call [self view]'.

I don't like that practise, but it has been handy in several occasions.

Thanks for sharing this!

mikeash - 2012-04-24 02:04:03

Tue, 24 Apr 2012 02:04:03 GMT

That article is interesting. It strikes me as a knee-jerk reaction from someone who is really used to the way things are done. I think that, taking a step back and looking at things objectively, the iOS way is much, much better. It's totally consistent and works the way you'd expect it to, whereas the Mac way of sort of doing kind of what KVC does but not quite means you end up with two different facilities that both search your objects for setters and ivars and manipulate them, but in subtly different ways.

Daniel - 2012-04-22 23:38:08

Sun, 22 Apr 2012 23:38:08 GMT

Funnily enough, I've just read Aaron Hillegass's "Real iPhone Crap, Part I" (http://weblog.bignerdranch.com/?p=95) from back in 2009, where he argued that the use of KVC in NIB loading in UIKit (and thus inferring outlets to be strong) was a bad idea — I'd love to know whether or not he changed his opinion about this!

Since I'd consider getting rid of the view without disposing of the view controller on the Mac as very uncommon, (and I think the absence of a viewDidUnload is a pretty good indicator for that) I don't really understand how he arrived at that conclusion anyways...

mikeash - 2012-04-17 16:53:14

Tue, 17 Apr 2012 16:53:14 GMT

Sean M: The situation is really easy under GC: make outlets, use them, and don't worry about it. GC is very nice when it works....

Andrew Bonventre: The reasons for being dubious about calling setters in init/dealloc is not simply because the setters may be overridden, but because you'd end up calling those overridden setters on a partially constructed/destructed object. That's not a problem in something like viewDidUnload. In fact, not only is it acceptable to call the setter there, it's really what you should do: screwing with ivars directly instead of using their accessors is generally a big no-no. init/dealloc are exceptions to this rule, but viewDidUnload definitely is not.

Rob C. Grant: Yes, it's fine to use a UIViewController and then do stuff with its view. You'll probably want to subclass UIViewController to add code to control the reusable view element, then keep that controller around and manipulate it from your higher level controller to fiddle with the view in question.

Rob C. Grant - 2012-04-14 21:57:25

Sat, 14 Apr 2012 21:57:25 GMT

I'm unclear on the implications of this article re: nibs that contain reusable interface elements. In such a case, is it appropriate to use a UIViewController to load the nib and then add the controller's view as a subview in some other view controller's hierarchy?

Andrew Bonventre - 2012-04-14 14:36:13

Sat, 14 Apr 2012 14:36:13 GMT

A tiny digression but this post sparked the question in my brain again...

Apple discourages dot syntax in init/dealloc but encourages self.myOutlet = nil; in viewDidUnload. What's the best convention, here?

I understand the reasoning behind not using self.bloop = blah; within the init and dealloc methods because of the possibility of those setter methods being overridden in a subclass amongst other reasons.

Is it simply for convenience that they encourage self.outlet = nil; within the boilerplate comments on every UIViewController's viewDidUnload method? What's your preferred method and why?

Matthijs Hollemans - 2012-04-14 03:43:33

Sat, 14 Apr 2012 03:43:33 GMT

On iOS with ARC, Apple now recommends making weak outlets for all subviews, but any top-level views besides self.view should have strong outlets as there is nothing but these outlets keeping those objects alive.

Using weak for subviews has the advantage that your viewDidUnload methods hardly have to do any work anymore, since the weak outlets will be automatically unloaded for you when self.view disappears.

However, if the nib contains any other top-level views (that you made strong outlets for), then these properties still need to be "nilled out" in viewDidUnload.

Sean M - 2012-04-14 03:28:02

Sat, 14 Apr 2012 03:28:02 GMT

I guess you omit garbage collection since it's basically deprecated now? Shame, because it would seem to be the easiest case of all. Reading the doc Avi linked to reminds me of how much I'll miss GC! :(

mikeash - 2012-04-13 19:02:30

Fri, 13 Apr 2012 19:02:30 GMT

Since top-level objects in iOS nibs aren't retained by the nib loader, they'll be destroyed as soon as everybody stops expressing interest in them. If the only connection to them is an assign or weak outlet, they'll be destroyed immediately once the nib is done loading, probably not what you want.

Eimantas - 2012-04-13 18:29:35

Fri, 13 Apr 2012 18:29:35 GMT

"weak can be a good choice for outlets to subviews on iOS"

Does this mean I can have `assign` type properties, in non-ARC environment, to subviews of top level objects when loading nibs on iOS so that I don't need to release them in viewDidUnload and dealloc methods?

mikeash - 2012-04-13 15:45:58

Fri, 13 Apr 2012 15:45:58 GMT

You still have to release the objects when using ARC, ARC just makes it really hard to do so. Yet another reason you should always use a Cocoa controller to load nibs instead of doing it yourself.

Avi Drissman - 2012-04-13 14:52:56

Fri, 13 Apr 2012 14:52:56 GMT

"Release each top-level object to balance the alloc sent when loading the nib"

Unless you're using ARC. From https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html#//apple_ref/doc/uid/10000051i-CH4-SW18 :

"If the File’s Owner is not an instance of NSWindowController or NSViewController, then you need to decrement the reference count of the top level objects yourself. With manual reference counting, it was possible to achieve this by sending top-level objects a release message. You cannot do this with ARC. Instead, you cast references to top-level objects to a Core Foundation type and use CFRelease."

(sob)

Remy "Psy" Demarest - 2012-04-13 14:37:42

Fri, 13 Apr 2012 14:37:42 GMT

In iOS, top-level objects and other objects are not initialized with a class-specific init.
There are two ways, either the type of object is known by IB (you didn't pull a NSObject cube into the nib), then the object is always initialized using -initWithCoder:, if the object is not known, then it uses -init only.