1

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 ?

Andrea
  • 26,120
  • 10
  • 85
  • 131
  • Why are you saying "the main view doesn't own none of them", if you add your view as subviews addSubview: add a strong reference to the view. – Luca Bernardi Mar 09 '13 at 08:52
  • Hi Luca, imagine that you are looking at a xib create automatically using the wizard during the process of creating a new view controller. You will find that the only one view on the screen is connected to the file's owner by the 'view' outlet. Everything that you will add to that view as a subview will be owned by it and if you create an outlet from them will be correctly referenced as weak or unsafe_unretained. Sometimes (but I don't think is a good practice) you will need to create more views and not already add them as a subviews, if you create outlet from those views it will be strong.->> – Andrea Mar 09 '13 at 17:44
  • that make sense. This new mechanism seems to evict the backing store of the "main view" a its subviews but will it evict also the backing store of the other views even if they are not owned by the main view? some hints here http://thejoeconwayblog.wordpress.com/2012/10/04/view-controller-lifecycle-in-ios-6/?utm_source=iOS+Dev+Weekly&utm_campaign=196e322709-iOS_Dev_Weekly_Issue_62&utm_medium=email – Andrea Mar 09 '13 at 17:46

0 Answers0