Note that there are some explanatory texts on larger screens.

plurals
  1. POUsing viewDidLoad after didReceiveMemoryWarning and viewDidUnload
    primarykey
    data
    text
    <p>I am still trying to understand the process of managing views when meory warnings occur. I received some <a href="https://stackoverflow.com/questions/8876212/proper-use-of-loadview-and-viewdidload-with-uiviewcontroller-without-nibs-xibs">good information in this answer</a>, but I still have questions. </p> <p>Suppose I have a <strong>view controller</strong> VC1 that contains a subview that is managed by <strong>view controller</strong> 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:</p> <pre><code>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. </code></pre> <p>At some time later, a memory warning is received in VC2. So VC2's didReceiveMemoryWarning is called, followed by VC2's viewDidUnload.</p> <p>This is where my understanding ends (if what I have already said is correct!)</p> <p>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.</p> <p>How, exactly does it get released? The didReceiveMemoryWarning executes in VC2. Does VC2 release its own view? If not, what is suppose to happen.</p> <p>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 <strong>view property</strong> 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. </p> <p>Well I walked through my second question, and may have answered it at the same time. Can someone confirm whether I understand this correctly? </p> <p>Also, I am still not clear (as in my first question) how and where VC2 view should be released.</p> <p>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.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COI'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.
      singulars
    2. COThey 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.
      singulars
    3. COView 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.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload