2

I am still trying to understand the process of managing views when meory warnings occur. I received some good information in this answer, but I still have questions.

Suppose I have a view controller VC1 that contains a subview that is managed by view controller VC2 (which has that subview it's view property). Initially, if I want to put the VC2 view into another the VC1 view, so I might do this:

UIView *VC2 = [UIView alloc] initWithFram...];
VC2.delegate = self;
... // other references to VC2, but not to it's view, yet.
[VC1.view addSubview VC2.view];  // At this point VC2 loadView is called automatically,
                                 // followed by VC2 viewDidLoad.

At some time later, a memory warning is received in VC2. So VC2's didReceiveMemoryWarning is called, followed by VC2's viewDidUnload.

This is where my understanding ends (if what I have already said is correct!)

What I expect to magically happen is that the view in VC2 and its resources can be released (for example, it may be one view that the tab bar controller references, but is currently not being shown), and this should work out alright if it can all be recreated by VC2's viewDidLoad method. Assuming that VC2's view is not vissible for the time being, it should be release.

How, exactly does it get released? The didReceiveMemoryWarning executes in VC2. Does VC2 release its own view? If not, what is suppose to happen.

Second question, if VC2's view has been released, suppose the view is needed again (like someone selectes the corresponding tab on the tab bar). My understanding is that VC2 loadView gets called if view property of VC2 is referenced. Initially it was referenced when VC1 added it as a subview using the property reference. A tab bar controller may call it up by reference through the view controller VC2, which is in the tab bar controller's viewControllers array. So I guess the tab bar controller will reference the view property, and that leads to VC2 loadView being called.

Well I walked through my second question, and may have answered it at the same time. Can someone confirm whether I understand this correctly?

Also, I am still not clear (as in my first question) how and where VC2 view should be released.

Is there a tutorial someone can point me to that walks through this whole process of releasiing views and view hierarchies in response to memory warnings, also expalining how the released views are reconstituted when they are needed? That would really help my understanding of this process.

Community
  • 1
  • 1
Draco
  • 1,003
  • 1
  • 10
  • 14
  • I'm confused. Are VC1 and VC2 view *controllers* or UIViews? You are not supposed to present two view controllers on screen simultaneously, partially to avoid the very confusion you are now experiencing. – jsd Feb 01 '12 at 18:56
  • They are view controllers. And that's not true at all. A tab bar cotnroller is a view controller (it's called a container view controller). It presents a view that is managed by another view controller. It is common practice to simplify software by managing complex views that are shown at the same time by using separate view controllers. If you have seen an authoritative explanation of what you are saying, I would like to see it myself. Please provide a reference. – Draco Feb 01 '12 at 19:32
  • View Controller Programming Guide http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/AboutViewControllers/AboutViewControllers.html Each content view controller object you create is responsible for managing all the views in a single view hierarchy. The one-to-one correspondence between a view controller and the views in its view hierarchy is the key design consideration. You should not use multiple content view controllers to manage different portions of the same view hierarchy. – jsd Feb 02 '12 at 00:11
  • And yes, that doesn't apply to tab bars... The VCPG makes a strong distinction between CONTENT view controllers and CONTAINER view controllers. Splitview, tabbar, etc can manage multiple Content VCs. – jsd Feb 02 '12 at 00:15
  • 1
    Apple's guidelines aren't as strict as you think they are. Earlier in the same docuemnt it says this: "Every view is controlled by only one view controller. When the view is assigned to the view controller’s view property, the view controller owns it. `Or the view might be a subview, in which case it could be controlled by the same view controller or a different view controller`." If you aren't flexible, you're making design challenges harder than they need to be. – Draco Feb 02 '12 at 00:36
  • You asked the question, I'm sorry you don't like the answer. I think you are the one who is making it harder by fighting the design of the system. If you have two CONTENT (not CONTAINER) vcs attempting to own the same view you are going to have problems in low memory situations where the view can't be unloaded due to it having multiple owners. If instead every view controller is responsible for its own subviews, the viewDidUnload/reload cycle is simple. If you follow the MVC principles correctly, views should be trivial to dispose of/reconfigure as needed. – jsd Feb 02 '12 at 15:10
  • Okay, just so you know I take your input seriously, I still couldn't stop thinking about this, because I do have view controllers managing complex subviews inside other views. Apple has formalized this in the iOS 5 release, and added methods in the UIViewController class to suppport this. See the section on 'Implementing a Container View Controller' in the latest class reference. I have been doing this already, but wasn't aware that Apple also found it worthwhile to make this a part of the OS until you raised your point. – Draco Feb 02 '12 at 19:34

0 Answers0