Re: Who owns a child view controller?
Re: Who owns a child view controller?
- Subject: Re: Who owns a child view controller?
- From: Alex Zavatone <email@hidden>
- Date: Thu, 13 Jul 2017 14:29:39 -0500
One thing that I had to learn was to break my expectations of when a view
controller (one that is tied to a navigationController) is deallocated.
My expectations initially were “oh, we’re closing it and going to another
screen, it will just be deallocated.”
Weeellll, no. It’s part of a stack of view controllers if it’s in a navigation
controller and the entire stack is what is needed for the user to be able to
travel back and forth within the list of controllers that are “under” that nav
controller.
I expect that if the app comes under memory pressure, the instantiated VCs will
be faulted to disk and if even more pressure, they may be deallocated.
But I’m not really sure about that.
The one thing that I am aware of is that, “just because the user moves on to
another view controller, that doesn’t mean that the one they left is
deallocated. I leave that to the OS to figure out. If I have a set of view
controllers that act as a module, I open a new storyboard, with a new nav
controller, so that I when complete, I can close the whole thing by dismissing
it and since there are no more references left, all the memory for the whole
section is just returned as everything deallocates. This approach has worked
worked pretty well for me for about 4 years now in iOS. It’s not applicable
everywhere though.
Cheers,
Alex Zavatone
> On Jul 13, 2017, at 4:57 AM, Jeremy Hughes <email@hidden>
> wrote:
>
>> On 13 Jul 2017, at 01:32, Jens Alfke <email@hidden> wrote:
>>
>>> On Jul 12, 2017, at 2:57 PM, Jeremy Hughes <email@hidden>
>>> wrote:
>>>
>>> I’m trying to understand memory management so I can avoid retain cycles and
>>> other issues.
>>
>> That’s fine. But using a weak reference to try to detect when an object gets
>> dealloced is fraught with peril, viz. this entire thread :)
>
> That was some test code I wrote to investigate a situation I noticed while
> debugging. The actual issue is whether an object (view controller) is
> deallocated rather than when it is deallocated.
>
>> On 13 Jul 2017, at 01:32, Jens Alfke <email@hidden> wrote:
>>
>> If you want to find out if your code is leaking by creating reference
>> cycles, just run it and ask either Instruments or Xcode to find leaks.
>
> I was hoping to avoid creating cycles in the first place...
>
>> On 13 Jul 2017, at 00:15, Quincey Morris
>> <email@hidden> wrote:
>>
>> I may be overlooking something important, but I see basically three tasks
>> you need to handle to avoid memory management bugs:
>>
>> 1. Strong references.
>>
>> 2. Weak references.
>>
>> 3. Unowned/unsafe references.
>
> I’ve abbreviated this summary - but the things that I find confusing are:
>
> 1. When to use unowned rather than weak. I’ve read Apple’s Swift book and
> other discussions, and one explanation I found is that unowned is a bit like
> forced unwrapping - you can (or should) use it when you’re sure that the
> reference will always be valid, and it saves you from having to use an
> optional. According to Greg Parker’s email there is also unsafe unretained
> which is different from unowned. I think that unsafe unretained is the same
> as unowned(unsafe) in Swift, but I could be wrong.
>
> There is a thread on Stack Overflow where people are confused about the
> difference between unowned and unowned(unsafe).
>
> https://stackoverflow.com/questions/26553924/what-is-the-difference-in-swift-between-unownedsafe-and-unownedunsafe
>
> According to a comment from Dave Abrahams (who I think works at Apple):
>
> "unowned and unowned(safe) do incur reference counting cost—that is the cost
> of safety, and why even make unowned(unsafe) available otherwise?—and it’s
> currently worse than regular strong reference counting cost because ARC isn’t
> optimizing for it. Neither throws an exception; they trap when misused,
> permanently stopping the program”
>
> But if unowned is a synonym for unowned(safe), I’m not sure what “Neither”
> means in the last sentence - is he talking about safe and unsafe unowned, or
> just unsafe unowned?
>
> Apple’s Swift book says:
>
> "The examples above show how to use safe unowned references. Swift also
> provides unsafe unowned references for cases where you need to disable
> runtime safety checks—for example, for performance reasons. As with all
> unsafe operations, you take on the responsiblity for checking that code for
> safety.
>
> "You indicate an unsafe unowned reference by writing unowned(unsafe). If you
> try to access an unsafe unowned reference after the instance that it refers
> to is deallocated, your program will try to access the memory location where
> the instance used to be, which is an unsafe operation.”
>
> At this point I’m pretty confused about the difference between strong and
> safe unowned. I understand that strong retains its reference, but it seems to
> me that Dave Abrahams and Apple’s Swift book are saying or implying that
> (safe) unowned also retains its reference - so the consequence of using
> (safe) unowned incorrectly is that it will create a retain cycle, whereas
> using unowned(unsafe) incorrectly will crash. But if unowned(safe) retains
> its reference, how is it different from strong (apart from whether ARC is
> currently optimising for it)?
>
> 2. When to use weak or unowned in closure capture lists (rather than default
> to strong) is also pretty confusing! Presumably the default strong option is
> correct for some or most closures, but I don’t have a very clear idea of when
> it’s not correct.
>
> 3. Whether (and when) it’s necessary to avoid using functions or class
> variables whose name begins with new or copy. I don’t think this is discussed
> in Apple’s Swift book (or I haven’t found where it’s discussed), but I think
> it’s necessary for classes that interface with Objective C in some way (e.g.
> subclasses of Cocoa classes).
>
> My experience of memory management in Objective-C and Swift (after many years
> of experience with C and C++) is that it mostly “just works” (as Apple say in
> the Swift book) - but there are many cases where you need a deeper
> understanding and it’s hard to find clear explanations.
>
> Jeremy
>
>
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden