Mark Smith#SwiftUI knowers: can anyone tell me why an existing Thing instance isn't deinitialzed when thing is set to nil? It's only deinitialized when a new Thing is assigned to thing.
This makes no sense to me. And it's bad if Thing is managing a resource.
Todd Thomas@marksmith the State property wrapper binds the lifetime of what it wraps to the lifetime of an onscreen view with a particular identity. It does that in this case by retaining a reference to the Thing instance created the first time a ContentView with a particular identity is added to the view graph SwiftUI is maintaining behind the scenes. Identity is determined explicitly or implicitly by factors like the view's location in the view graph.
@marksmith If you want a view to observe an instance of a reference type whose lifecycle you manage yourself, use the Observable attached macro on your type, create and manage an instance elsewhere, and pass in the instance to the view initializer.
@toddthomas Say I have a stupid simple app with one view that shows a Thing. It has a popup menu that lists the names of different Things. When an item is selected, a new Thing is created and becomes the one displayed.
If I understand you, @State can’t be used to hold the only reference to the current Thing if I want the normal ARC lifecycle. I need some long-lived ThingMaker class instance outside of the view to hold the reference instead. Is that correct?
@marksmith I see State as the tool that gives a Thing instance the lifetime we intuitively expect of a property that belongs to a "view”. We're thinking of the lifetime of the view on screen, which is very different from the lifetime of a View-protocol-implementing struct value which lives briefly on the stack as SwiftUI creates them many times to render and update the view on screen. So I think State is what you want for a view that shows one Thing at a time.
@marksmith I'm away from Xcode right now, will make an example later today.
@marksmith I think this example shows how the State property wrapper allows the Thing instance to persist as long as the user desires, but not be leaked, even though many new ThingPicker values are created by SwiftUI as it updates the view graph. Let me know if I’ve misunderstood the question you were asking. 😅
@toddthomas Thanks Todd. The issue I see is in between persisting long enough and leaking: the objects can last much longer than expected, because they seem to be held by SwiftUI itself after the application code is done with them, for some internal reason.
cont’d…
@toddthomas In UIKit, if an instance variable in a UIViewController is the sole reference to an object, setting it to nil will release that object. I can use the Resource Acquisition is Initialization technique to free resources in a timely manner. That seems not to be the case with SwiftUI.
I’m not arguing it’s a bug, just that it’s (to me) unexpected behavior. A leaky abstraction maybe.