So in viewDidUnload we need to assign nil to any of our outlets, but what about dealloc. If we have used a property without an ivar, how can we release our outlet give that we are not supposed to use any accessors in an init or dealloc?
It seems to me that the only pattern which would allow us to release our outlet without an accessor is using a property backed with an ivar, so we can manually release our ivar in dealloc without using its accessor, however this is the one option which Apple's code-generation doesn't support.
In this manner you can let the compiler to create an instance variable for you. But you can also declare your instance variable and tell the compiler to use that. The Apple Memory Management guide says that you have to avoid accessors methods in init or dealloc methods when you have non-ARC projects.
So, for example:. This is very important in non-ARC projects. The reason is that, if there is no accessor, KVC will assign the nib object to the instance variable and will put a retain on it. If you forget to release it, you could have a memory leak.
Using an accessor force you to release that object at the end. I strongly suggest to read friday-qanib-memory-management by Mike Ash. It's a very cool article on nib and memory management. The current recommended best practice from Apple is for IBOutlets to be strong unless weak is specifically needed to avoid a retain cycle.
And the last option I want to point out is the storage type, which can either be strong or weak. In general you should make your outlet strong, especially if you are connecting an outlet to a subview or to a constraint that's not always going to be retained by the view hierarchy. The only time you really need to make an outlet weak is if you have a custom view that references something back up the view hierarchy and in general that's not recommended.
I asked about this on Twitter to an engineer on the IB team and he confirmed that strong should be the default and that the developer docs are being updated. I just got the same problem recently. What would change if you declared the outlet weak? You can give it a try and run the application. If there seemingly is no difference in behavior, then why is this important? Why are some developers declaring outlets strong while others define them weak?
To understand why outlets can be declared strong or weak, you need to be aware which objects keep a reference to which objects. Reference counting. Every view controller keeps a reference to the view it manages. That reference is strong. The view should not be deallocated as long as the view controller is alive. That makes sense. You can verify this by opening ViewController. This takes you to the public interface of the UIViewController class.
As you can see, the view property is declared strong. What happens if a view is added to the view of the view controller? A view always keeps a strong reference to the subviews it manages. May 20, He is asking a question that most of us have when beginning with Interface Builder and Outlets. I personally believe that it is good coding practise to always match a retain with a release. This is also the reason why you never see the OS get into dealloc on quit. It only bothers with dealloc if your app is not already quitting.
For example if you alloc and dealloc objects during the lifetime of your app. There are two ways that an outlet can be set up. One is to simply add the keyword IBOutlet to the instance variables. The second method, which you would use if you want to access those members from outside of this class, is to attach IBOutlet to the matching properties.
Both achieve the same goal of getting the memory address assigned to them when a XIB file is loaded and all contained class instances get unarchived.
0コメント