If an application receives a low memory warning and a view controller releases the view, how does one reload the view the next time it's needed. I have my views defined in a .xib file and on earlier iphones, the views are being set to nil. Where/when/how do I recreate these views if they are removed?
I was writing my code pretty much horribly wrong. I was setting views to nil in viewDidUnload but all my creation was done in init. So when the application received a memory warning, when I went back to that view controller, the views were gone. This answer helped me realize my mistake; namely, that additional views could be added to viewDidLoad so that if they are released due to memory warnings in viewDidUnload, they can be recreated.
Related
In iOS6 the method viewDidUnload became deprecated, the memory management has changed a lot for a UIViewController. Here is a little brief about the new patterns.
The part that occupies more memory in a view controller is the view (and of course huge data that you would eventually create). The view itself it doesn't consume so much memory, is the backing store, the part that is drawn (for the most curious is the CABackingStore). This new pattern seems to check as volatile the memory occupied by all the backing stores owned by view controllers' views that are not displayed in a window. When a memory warning comes this backing store will be purged from memory. With this method you can save the process of recreating the view that is quite expensive.
Apple says that is safe to remove viewDidUnload/viewWillUnload from also iOS5 project and even if you set the deployment target to iOS5 the templates don't show those methods. I understand that if the outlets owned by the view are weak, when you release the view controller's view in the superclass implementation everything will be dealloc correctly without leaks or zombies thanks to ARC.
Since I really appreciate this new approach I'm not confident with this kind of situation: let's suppose that we have a view controller and its view, this view is just a content view that will host different views created in the view controller's xib, changing them at runtime dynamically. When you create outlets for this views they are automatically created as strong and that makes sense because the the "main view" doesn't own none o f them. Regarding the new rules the backing store of this views will not be signed as volatile since they are not owned by the main view in iOS6 and in iOS5 (if I remove the viewDidUnLoad) they will be not released for the same reason.How can i manage this situation? It will be correct to release them inside the didReceiveMemoryWarning? but were can I recreate them in iOS6 if the view will be loaded only once ?
I decided to use storyboards in a project I have been doing. When the app launches it does the right thing of awakeFromNib and then viewDidLoad, but when the app has finished segueing to another view, it doesn't call viewDidUnload and, I think, neither does dealloc. I have used Apple's Instruments and doesn't show any memory leaking.
Just to note, I am using custom segues and testing this by inserting NSLogs into the methods. Has anyone else come across this?
Just want to update: dealloc actually is called but not viewDidUnload.
The viewDidUnload method is solely for the purposes of didReceiveMemoryWarning (i.e. when the view is being removed to recover some memory, but the view controller is not). If you want to see viewDidUnload while running in the Simulator, push or presentViewController to a secondary view, then generate a memory warning from the Simulator's menus. I quote from the UIViewController Class Reference:
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. [The viewDidUnload 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.
At the time this method is called, the view property is nil.
viewDidUnload is called when the view is actually unloaded. If you want to clean up your resources when the view is not displayed put that in viewDidDisappear.
If you want to see what is happening with viewDidUnload, run your app in the simulator and from the menubar choose Hardware | Simulate Memory Warning.
Under memory pressure, views that are not on screen are removed and that is when the viewDidUnload method is sent.
in my app, sometimes I get a level 1 memory warning which I think is acceptable given the amount of work it is doing. When that happens, it calls the viewdidunload for one of the views which is part of the tabbarviewcontroller. In the viewdidunload, i set the outlets to nil which I think is totally normal.
The issue arises if I try to access that class again. Since it was deallocated, it will throw a bad access error which prevents me from showing that view again. If I don't set those outlets to nil then it won't crash which is normal but the convention is always to set any outlets to nul in the viewdidunload.
Any pointers for handling memory warnings in this case? I don't want to delete the code i have in the viewdidunload method since it is going against the convention.
I forgot to add that i subclassed the tabbarcontroller >_<
In that case, again the subviews added to xib file will be allocated when you load that view again. And if you want to customize something, do that in viewDidLoad method.
Where do the views which were deallocate get allocated? It sounds like you are deallocating a view in viewDidUnload that was not allocate in, for example, viewDidLoad. Instead it might have been created somewhere else, so it does not get recreated then the viewController's view is reloaded.
I'm developing an app to browse online photos, and sometimes received memory warning(level 1), after that, if I go back to last UIViewController(in a NavigationControll), I found that some custom UIView lost, I cannot get them back, but I can create new such UIView
does anyone know the problem?
The memory warning prompts the os to dump any unneeded views. If you create them in IB, or in the viewDidLoad or loadView method in your view controller they'll be re-created when your view re-loads. You could also have your view controller retain them specifically, but that'll have a larger memory footprint than just re-creating them whenever they're needed.
I should say, loadView is only called if you don't use a nib for creating your view, so viewDidLoad is probably where you want to put them.
It's expected behavior. You can override didReceiveMemoryWarning (i.e. do nothing and don't call on super); but what you really want is to handle those situations correctly, i.e. set the views up again if necessary.
I am introducing auto-rotation to my app and I'm having an issue with a memory warning. Whatever orientation I start my app in, as long as the device remains in that orientation, I get no memory warnings. However, the first time I rotate the device the following warning is placed on the console: Safari got memory level warning, killing all documents except active. When this happens all view controllers, other than the one be viewed, are unloaded - this produces unexpected behaviors when navigating back to view controllers that should normally already be on the stack. The app never crashes and this warning occurs once upon the first rotation, after that it never happens (until I stop/start the app again). Also, this only happens on the device - no memory warning when running in simulator.
Has anyone seen this behavior? In any case, does anyone have any suggestions on what I might try in order to remove the memory warning.
Thanks in advance.
You can't assume that memory warnings will never happen; you have to handle them gracefully. Suggestions:
Check for memory leaks with Leaks (note that it doesn't catch all leaks).
Fix your view controllers to handle a view reload. Specifically (unless you override -(void)loadView), it'll call -(void)viewDidUnload on a memory warning and -(void)viewDidLoad when it becomes visible again. You might fix this by saving state in the view controller and restoring it to the views in -(void)viewDidLoad.
If you can't be bothered handling the memory warning, implement -(void)didReceiveMemoryWarning and do not super-call (i.e. comment out [super didReceiveMemoryWarning]). This is lazy, and might cause a crash if your app ends up using too much memory (background apps like Safari and Phone will be killed first).
You can test memory warning behaviour with the "simulate memory warning" option in the simulator.
Memory warnings are part of a normal iOS behavior, due to its limited memory, especially now that multi-tasking is supported.
UIKit doesn’t only allow navigation back from a view controller, but also allows navigation to other view controllers from existing ones. In such a case, a new UIViewController will be allocated, and then loaded into view. The old view controller will go off-screen and becomes inactive, but still owns many objects – some in custom properties and variables and others in the view property/hierarchy. And so does the new visible view controller, in regard to its view objects.
Due to the limited amount of memory of mobile devices, owning the two sets of objects – one in the off-screen view controller and another in the on-screen view controller – might be too much to handle. If UIKit deems it necessary, it can reclaim some of the off-screen view controller’s memory, which is not shown anyway; UIKit knows which view controller is on-screen and which is off-screen, as after all, it is the one managing them (when you call presentModalViewController:animated: or dismissModalViewControllerAnimated:). So, every time it feels pressured, UIKit generates a memory warning, which unloads and releases your off-screen view from the view hierarchy, then call your custom viewDidUnload method for you to do the same for your properties and variables. UIKit releases self.view automatically, allowing us then to manually release our variables and properties in our viewDidUnload code. It does so for all off-screen view controllers.
When the system is running out of memory, it fires a didReceiveMemoryWarning. Off-screen views will be reclaimed and released upon memory warning, but your on-screen view will not get released – it is visible and needed. In case your class owns a lot of memory, such as caches, images, or the like, didReceiveMemoryWarning is where you should purge them, even if they are on-screen; otherwise, your app might be terminated for glutting system resources. You need to override this method to make sure you clean up your memory; just remember you call [super didReceiveMemoryWarning];.
An even more elaborate explanation is available here: http://myok12.wordpress.com/2010/11/30/custom-uiviewcontrollers-their-views-and-their-memory-management/