In Objective C, if a ViewController has a UIKit object property, lets just say a view, and is instantiated in viewDidLoad, followed by being added to the subview, in order to remove it out of memory, both removeFromSuperview() and setting the object to nil must be done (if I'm not mistaken, but I could be...)
However, in Swift, only things with the optional type can hold a value of nil.
My question is, if I would like to animate things like UILabels or UIViews within my application, and later have them disappear (to both the user and removed from memory), would having that UIKit object being removeFromSuperView() be enough? or would I have to make all objects that I'm trying to animate optional, removeFromSuperView() and then set them to nil?
I apologize for my poor articulation. If further clarification is needed, please let me know. Much thanks for your input.
If you want the weak property objects to deallocate, then yes, you have to set them to nil or wait for the owning object to deallocate.
Objects in properties that are not weak will get a release call when the parent object is deallocated. This means the objects will also get deallocated if nothing else is keeping a reference to them.
If you create a temporary UILabel that's not a property of the View Controller and animate it and then removeFromSuperview() it, then it should disappear from memory as well.
As it was retained (refcount: 1) when the function creating the animation was running, later by the view hierarchy (refcount: 2), the function ended (refcount: 1), so only the view hierarchy was retaining it. If you removed it at the end of animation (refcount: 0) it is deallocated.
Related
So I had a project that supported iOS 4, so all my IBOutlets were __unsafe_unretained even IBOutlets that were in the nib but outside the controllers main view (Separate View in the same nib) and all worked great.
So the time has come and now the client wants to support only iOS 5 so our team changed all the __unsafe_unretained IBOutlets for __weak IBOutlets but now the IBOutlets that are not inside the main view are set to nil (except in viewdidload) so we are unable to add them later.
If I think about it, it makes sense because if no view (main view) is retaining those IBOutlets they should be deallocated and zeroed (I don't know if that is the correct word), so the solution is to remove the __weak from those IBOutlets
But what doesn't make sense to me is Why the different behavior between unsafe_unretained and weak, in my head the unsafe_unretained ones should be deallocated and when the app tries to access them, they should point to an invalid reference and then the app should crash.
I thought that unsafe__unretained was the same as weak but without the zeroing.
Am I missing something here?
Thanks.
I thought that unsafe__unretained was the same as weak but without the zeroing.
It is, yes.
When Cocoa loads the nib, it creates all the objects autoreleased, so they are still there when viewDidLoad is invoked. However, the autorelease pool has a lifetime that ends when control returns to the run loop. At this point all the objects that aren't owned by anything will go away so any weak outlets will be zeroed at that point.
For most outlets, this is not a problem because objects in the NIB are already generally owned by something anyway. So, for instance, a button in a view is owned by its parent view. Having strong outlets that point to that button are therefore overkill or worse might result in a retain cycle.
Top level objects obviously don't have a parent view to own them so they need to be owned by something else e.g. a controller or "File's Owner". If you are finding stuff disappears, you need to create a strong IBOutlet for it in File's owner.
For more detail, see Apple's docs.
For future searchers who come across this question, I think CRD's Stackoverflow answer to a similar question may explain. Even though the object has been deallocated, the memory that's referenced by the unsafe unretained pointer (which contains the actual object data) is not necessarily zeroed, so things may appear to behave properly until that memory is actually reused/modified/zeroed.
You are correct, the app will crash when trying to access deallocated objects through your stale __unsafe_unretained references.
The reason it doesn't is very likely because the objects are being referenced by some other part of your app with strong references.
Try running with zombies enabled, that should cause an immediate crash when dereferencing the presumedly stale pointers.
I'm fairly new to ARC for iOS (and pretty new to iOS in general) and I have a few quick questions about ARC.
~ In a View Controller, if I do not have statements in my viewDidUnload() method setting my properties to nil, will the properties' memory still be freed when my view controller is released? If so, why do I need to explicitly have this viewDidUnload method?
~ In objects that are not View Controllers, where should I set the properties to nil at? In dealloc? What about primitive properties such as #property BOOL isActive;...do I need to set them equal to nil/zero?
Thanks.
You don't need to set your properties to nil as long as they're weak references. IBOutlets should generally be weak references, since they the view controller contains a strong reference to the view, which in turn contains strong references to all of its subviews. (If you have IBOutlets that aren't part of that view hierarchy, they should be strong.)
You shouldn't need nil or zero anything, objects or scalars. Xcode will insert nilling statements when working with Interface Builder, but this is it still generating code for pre-ARC Objective-C.
You probably don't even need a viewDidUnload; it's only called in special circumstances, when there's low memory stress. Thus, you can't depend on it for cleaning up. Your IBOutlets should be weak, so they'll be cleaned automatically when the view is purged from the viewcontroller (and they'll be restored if the view is reloaded).
I'm assuming here that you're writing a new product, which means you're targeting iOS 5 or later only. If you're targeting iOS 4 in a new product, you really shouldn't be. The world has moved on, with 80% of the market on iOS 5 or later. And that's today. Going forward, it's going to be even harder to avoid iOS 5 features for an even smaller percentage of people.
Memory management for #properties is handled automatically under ARC. For times when you have set yourself as delegate, it is common to set the delegate to nil before going away (in viewWillDisapear for instance) so that future calls to delegate don't reference garbage. Stay tuned for the soon-to-be-posted WWDC videos for the latest guidance.
In viewDidUnload you need to set outlet references to nil, because ARC will release them and you do not want to accidentally use them after that happens.
You don't have to do anything with properties, they will be handled automatically. In fact you really do not normally even have a dealloc method any more with ARC.
Using xcode 4.2 for iPhone app, without ARC ---
When I create an outlet using the interface builder xcode adds two lines of code to my viewController. One in viewDidUnload: -- [self setMyOutlet:nil] and second in dealloc -- [myOutlet release].
I understand the latter (the release). But why set the outlet to nil in viewDidUnload. Doesn't viewDidUnload get called before dealloc and won't setting the outlet to nil negate the release operation in dealloc? Setting to nil makes sense I would think for building a Mac application which is using garbage collection -- but it doesn't make sense for an iPhone app.
Why does the interface builder do this? Should I delete the lines which set the outlets to nil?
viewDidUnload may be called and may be not called. It depends on the current memory usage. dealloc is a place where you should clean all your properties (like arrays, custom objects). In viewDidUnload you clean views and perhaps objects created to support the view. viewDidUnload mean that your view is unloaded (but not whole view controller) and it may be created and loaded again (in viewDidLoad, of course) in the future.
Why to nil - Objective-C Difference between setting nil and
releasing
Understanding How Views Are Loaded and
Unloaded
viewDidUnload is not called everytime before a dealloc, see what the apple docs say..
When a low-memory condition occurs and the current view controller’s
views are not needed, the system may opt to remove those views from
memory. This method is called after the view controller’s view has
been released and is your chance to perform any final cleanup. If your
view controller stores separate references to the view or its
subviews, you should use this method to release those references. You
can also use this method to remove references to any objects that you
created to support the view but that are no longer needed now that the
view is gone. You should not use this method to release user data or
any other information that cannot be easily recreated.
so the idea behind it is too release any unwanted objects which can be created easily.
Now coming to the part where it sets the properties to nil.. it does so because this way you release all the memory and set the objects to nil (thus bringing your down your memory usage) and after this if a dealloc is called your app will not crash as in objective-c you can send release messages to nil objects..
I would advise you to read the apple ViewController Programming Guide , it will clear a lot of your questions.... hoping this clears some of the air.. :D
Subviews added to a view are automatically retained by the view. Suppose you want to have a separate pointer to the same subview so you don't need to constantly retrieve it via its tag.
What type of #property is necessary for such a case? I assume that setting the property to retain is not a good idea since the main view is already retaining it? Should it be assign?
Or, is using #property entirely unnecessary here unless you plan to re-assign it later or refer to it with dot notation?
You can use either retain or assign.
Of course, if you use retain, you have to set the property to nil or release its object in viewDidUnload and dealloc.
The reason some people prefer retain is because it means the property is still valid in viewDidUnload. So if you have other cleanup to do, and that cleanup requires the view to still exist, you can do it in viewDidUnload.
If you use assign, you don't have to set the property to nil in viewDidUnload and dealloc (though it would be good practice). However, by the time you receive viewDidUnload, the view has already been released, so you can't use it at that point for other cleanup. Instead you have to override didReceiveMemoryWarning to do the cleanup before calling [super didReceiveMemoryWarning].
In iOS 5.0, you can do the cleanup in viewWillUnload instead of overriding didReceiveMemoryWarning.
Consider these two things:
There's no problem with retaining an object several times provided that each retain is balanced with release. With respect to properties, this just means that you should set your property to nil when you're done with it.
The basic idea behind memory management in Objective-C is that you worry about retaining the objects that you're using and let other objects worry about the objects that they're using.
Considering these, I'd advocate using retain. If you rely on he fact that a view retains its subviews, you've suddenly made your code dependant on external behavior. I'm not saying that UIView is likely to stop retaining its subviews, but if you keep a non-retained reference to a subview and later remove that subview from its superview you're code is likely to crash.
Some folks do use assign for outlets pointing to subviews when they know those subviews will never be removed. Personally, I don't see the point of relying on another object to retain something for you when retaining that thing yourself is so simple and cheap.
Is there any way to detect when an NSView will be dealloc'ed?
The reason is, I have some simple delegates (such as an NSTextField delegate that handles -control:textView:doCommandBySelector: to allow the return/tab keys to be entered). I'd like to just stick this delegate object in the nib, wire up the NSTextField's delegate connection and have it work.
And it does work, but the delegate is never released even after the NSTextField it is linked to is released, so the delegate object leaks.
I'd like the delegate object to be able to detect when the NSTextField is dealloc'ed, but I can't think of any way to do this, which leaves me having to store a separate link to the delegate object from some other controller and manually release it at some point which is very much less than ideal. Any ideas?
I've had a good look for this previously, and there doesn't appear to be any way to observe when an object is deallocated. I have seen one way to do it in a weak pointer class, but it involves isa swizzling, which can get nasty. Here is the website: http://www.cocoadev.com/index.pl?WeakPointers
Objects that are created from a nib file should be deallocated when the owner of the nib is deallocated, unless they are retained elsewhere. For example, when an NSWindowController is deallocated it will release any objects that were created when the nib was loaded. If your delegate objects aren't being deallocated, maybe it's because they are retained elsewhere, or there is a retain cycle.