I don't understand when I should implement something in viewDidUnload versus viewDidDisappear. What's the difference between the two?
For instance, I'd like to send an NSNotification when the view controller is removed from the view hierarchy. Between these two methods, does it matter where I post that notification from?
https://developer.apple.com/documentation/uikit/uiviewcontroller
This is with reference to apple's documentation:-
viewDidUnload:-
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.
viewDidDisappear:-
Notifies the view controller that its view was removed from a view hierarchy that is everytime view dissapears or move to other view.
viewDidDisappear is called every time when the view is disappears or you go to other view and viewDidUnload is called when the controller’s view is released from memory. (Deprecated in iOS 6.0. Views are no longer purged under low-memory conditions and so this method is never called.) see the reference.
Related
Apple says in the viewWillAppear Documentation
This method is called before the receiver’s view is about to be added
to a view hierarchy and before any animations are configured for
showing the view.
What does this sentence means
before any animations are configured for showing the view.
I am actually expecting the viewWillAppear to be called when the view is added in to the view hierarchy but when i come back from the background app to the foreground it also calls viewWillAppear when the view controller is already in the view hierarchy. Does it have to do some thing with the sentence
before any animations are configured for showing the view.
also the similar thing happens if i switch the tabs or some modal view controller is dismissed from my view.
The most classic and reliable method for the purpose you need is viewDidLoad.
viewWillAppear/viewWillDisappear and similar methods are designed to be called multiple times, viewDidLoad - only once, when the view first loads itself on the navigation stack, for example.
I have an application where the user can push infinitely deep into views (pushing onto nav stack). At some point, there will be a memory warning. I'd like to remove view controllers from the navigation controller and dealloc them. If the user goes back to those view controllers, I'd like to recreate the view controllers and push them back into the correct position in the stack.
Is this the right way to be thinking about this problem?
Is there an open source project that does this? It doesn't seem like an uncommon issue and I'd rather not reinvent the wheel.
There was a time where you needed to make sure that calls to viewDidLoad and viewDidUnload matched properly so that memory warnings could be handled this way. Since iOS 6 this is no longer necessary.
As it says in the documentation for viewDidUnload:
In iOS 5 and earlier, when a low-memory condition occurred and the
current view controller’s views were not needed, the system could opt
to call this method after the view controller’s view had been
released. This method was your chance to perform any final cleanup. If
your view controller stored separate references to the view or its
subviews, you could use this method to release those references. You
could 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 would not use this method to release user data
or any other information that cannot be easily recreated.
In iOS 6 and later, clearing references to views and other objects in
your view controller is unnecessary.
If you're manually keeping large objects in memory, such as image or video data, then you can override didReceiveMemoryWarning to release those objects where necessary.
I have a UINavigationController with a UIViewController pushed onto it. In my viewControllers view, I have two subview UIScrollViews. I recreate these scrollviews every time in the viewWillAppear method in my viewController and add them as subviews to my viewcontroller's view. I am using ARC, should I be destroying the two scroll views in viewDidDisappear method? What is better practice for memory usage.
EDIT: I did some investigation, and without removing the scroll views and setting them to nil in the viewDidDisappear method, they are not released. The viewcontroller's view gets an increasing number of subviews as viewWillAppear is called. As I mentioned in the comments, I never deallocate my main viewcontroller. It always stays on the navigation controller's stack. Why must I manually release the scroll views?
It may not be necessary to do anything at all. If your UIViewController is removed from the screen and is then being deallocated, it will automatically deallocate its view hierarchy (including subviews you have added). An easy way to check for this is to override the dealloc methods of the classes you're interested in (using an ObjC Category method added to the class), and log a message to indicate they've been removed.
A colleague and I have been designing our code so that our view controller objects are being allocated within the viewDidLoad method of our controller objects. We did this a lot and the object graph seemed to come out just fine. After a while we found the need to add another layer above our current view controller hierarchy that would own, allocate, and release our previous parent view controller.
This got me thinking about low memory warnings and view did load. Before, our views were always visible and thus wouldn't be released if a low memory warning occurred, but now there is a chance of that happening. If it does, it seems like when the views are reloaded, they will allocated new memory for new view controllers.
Will this cause widespread memory leaks? Or will the fact that we used retained declared properties save us, since the old controllers will be released automatically? Are there styles or conventions I should consider? Thanks for the help!
If you do create your view controllers in viewDidLoad, you should release them in viewDidUnload. True for pretty much any object, not just view controllers.
But I would not be surprised if you say "Wut!?" If your view controllers need to keep their state through memory warnings, then you don't want to release them. But it will be no better if you replace them with new ones that have fresh state.
It probably doesn't make sense to create view controllers in viewDidLoad. Create them in initWithNibName:bundle: (and release them in dealloc). The design pattern is that view controllers stay around, their views can come and go. If your subordinate view controllers have anything memory-intensive, release just that object in their viewDidUnload. Then on a memory warning, you will still free up a lot of memory, but all your view controllers will stay around in a low-memory usage state, retaining only a few flags, lists of indexes, etc., that they will need to restore their views when requested.
If you are explicitly releasing each view controller that is not needed any more you will not cause any memory leaks. Usually when you present a view controller the object that is doing the presenting will retain the controller for you, so you can release it if you don't need access to it anymore. But if you are using a UINavigationController and you are pushing new view controller's then you should be implementing the viewDidUnload method. This is straight from Apple's documentation:
After it is loaded into memory, a view controller’s view remains in memory until a low-memory condition occurs or the view controller itself is deallocated. In the case of a low-memory condition, the default UIViewController behavior is to release the view object stored in the view property if that view is not currently being used. However, if your custom view controller class stores outlets or pointers to any views in the view hierarchy, you must also release those references when the top-level view object is released. Failure to do so prevents those objects from being removed from memory right away and could potentially cause memory leaks later if you subsequently overwrite any pointers to them.
There are two places where your view controller should always clean up any references to view objects:
The dealloc method
The viewDidUnload method
If you use a declared property to store a reference to your view, and that property uses retain semantics, assigning a nil value to it is enough to release the view. Properties are by far the preferred way to manage your view objects because of their convenience. If you do not use properties, you must send a release message to any view that you explicitly retained before setting the corresponding pointer value to nil
I set up a detail view, do I have several Nib files that get loaded depending on what item is selected in the root view controller's table.
What I've discovered is that for the Nibs' classes, viewDidUnload is never called, whereas viewWillDisappear is called and dealloc of course is also called.
Anybody know why this would be?
Thanks.
I believe viewDidUnload isn't normally called when a view disappears from view. The reason for this is because dealloc will typically take care of all the memory dumping, so it doesn't need to call viewDidUnload first.
I think an example would help identify when viewDidUnload is called. Let's say you have a UINavigationController and you've pushed on a new view. This new view is very heavy on memory usage, so the app tries to shore up some resources. It does this by seeing if any Views are loaded that aren't currently on the screen. If so, it calls viewDidUnload where ideally you remove things that you built in loadView or viewDidLoad. Then when you go back to that view, it calls loadView or viewDidLoad again to re-build what it dumped off in viewDidUnload.
But if it doesn't need to free up memory to show your detail view, it won't call it in the normal processing of it. That's why viewWillDisappear is called (and dealloc) but never viewDidUnload.
From Apple's documentation:
When a low-memory warning occurs, the UIViewController class purges
its views if it knows it can reload or recreate them again later. If
this happens, it also calls the viewDidUnload method to give your code
a chance to relinquish ownership of any objects that are associated
with your view hierarchy, including objects loaded with the nib file,
objects created in your viewDidLoad method, and objects created lazily
at runtime and added to the view hierarchy. Typically, if your view
controller contains outlets (properties or raw variables that contain
the IBOutlet keyword), you should use the viewDidUnload method to
relinquish ownership of those outlets or any other view-related data
that you no longer need.
UIViewController Class Reference