This is a curiosity question (unless it proves to have created a memory leak, then it's real). I have often created custom UITableViewCells for my projects before ARC, but this is the first time I've had an opportunity with ARC and Storyboards. It's written often that the best practice with ARC when dealing with IB assigned views (UITextField, UIImage, etc.) that property that holds the reference be set to "nil" in the viewDidUnload override in the UIViewController.
My question in this case is concerned when you subclass a UIView instead of a UIViewController. For example the UITableViewCell. I have set up a Custom table view cell in my prototypes and added some control views to it. I then created a subclass of UITableViewCell and assigned it to the prototype for IB to return when it dequeues. I created some IBOutlets and linked the control views to these IBOutlets. All fairly typical stuff. My question is that since I don't have anything to set the IBOutlets to nil, have I created a memory leak?
Thanks for any advice.
Only you can know if you have created a memory leak because it depends how you have your structure, however you probably havent. In arc it is much harder to create a memory leak since the retain release is handled by you.
But here is what you need to know.
First of all, setting things to nil in the view did unload method is only necessary to set in a view controller, but this is only because that view controller might be holding STRONG reference to certain elements in a view. Remember that in ARC objects are released when there are no strong references to them. When you add an element to a view using the IB this view has a strong reference to the element. If you additionally create a STRONG property in the viewcontroller to this element now you have 2 things pointing the element. If there is a low memory condition and the system wants to free up some memory (releasing non visible views) that is when the viewdidunload is called (to nil possible strong reference to elements in the view and to nil other objects that were for that view but can be easily recreated)
Your concern might be in hooking up stuff to the IB on the UITableViewCell. As long as you hook up these controlls to the prototype cell that you designed then it is perfectly fine. Remember that this prototype is a container for all your controls in that cell so the table should be managing the memory for these (when not needed everything in that cell will be unloaded or reused)
Important: You should hook up the controls to the table view cell, not
to the view controller! You see, whenever your data source asks the
table view for a new cell with dequeueReusableCellWithIdentifier, the
table view doesn’t give you the actual prototype cell but a copy (or
one of the previous cells is recycled if possible). This means there
will be more than one instance of PlayerCell at any given time. If you
were to connect a label from the cell to an outlet on the view
controller, then sev- eral copies of the label will try to use the
same outlet. That’s just asking for trouble. (On the other hand,
connecting the prototype cell to actions on the view controller is
perfectly fine. You would do that if you had custom buttons or other
UIControls on your cell.)
raywenderlich.com Page 149
iOS5 by Tutorials Beginning Storyboards
Related
In my application, I thought it would be a good idea to create a subclass of UITableViewContoller (call it GenericTableViewContoller) which has a few prototype cells created in Storyboard that are reused throughout the app.
Now, what I wanted to do was to create a subclass of GenericTableViewContoller (say SpecialTableViewController) that has some other prototype cells created in Storyboard that are used only in SpecialTableViewController.
Thus, I have two scenes in my main storyboard, one for GenericTableViewContoller and one for SpecialTableViewController, each with their own set of prototype cells.
The problem I am running into, is that SpecialTableViewController gets nil prototype cells when I call dequeueReusableCellWithIdentifier: for a cell identifier declared in the GenericTableViewContoller scene. Cells declared in the SpecialTableViewController scene dequeue just fine.
Is this expected behavior (I have a strange suspicion it is)? Do I have to call registerNib:forCellReuseIdentifier: in SpecialTableViewController to actually get them registered from the other scene? Any simple way to get around this?
Is this expected behavior (I have a strange suspicion it is)?
Yeah, this is the expected behavior. The core concept here is that the storyboard is a object-instance designer, not a class designer. For example, you're free to make three scenes, each with the same view controller class, but all with different view layouts.
There isn't an simple way to share prototype table cell layouts between different table view instances short of putting them into their own XIB, and using -registerNib:forCellReuseIdentifier: and manual segues.
When a view controller is first instantiated, it usually creates or
loads objects it needs through its lifetime. It should not create
views or objects associated with displaying content. It should focus
on data objects and objects needed to implement other critical
behaviors.
The above is from the iOS reference :
http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/ViewLoadingandUnloading/ViewLoadingandUnloading.html#//apple_ref/doc/uid/TP40007457-CH10
The documentation goes on to describe a view load sequence with Storyboard.
My question are :
1
Since a view controller would be associated with a nib file, which contains view objects; And its "viewDidLoad" method seems to be designed for configuring view objects at load time. So how should the documentation's suggestion :
"should not create views or objects associated with displaying content"
be interpreted ?
2
Does question 1 related to whether we use Storyboard or not ?
Not sure I get your question right, but here's my explanation:
initialization and view creation are two separate steps. Let's say I have a view controller with table as IBOutlet which should display a list of recipes stored in core data. In my initialization method I'd fetch the data from CoreData and store it in an array or fetched results controller. I don't need table for that, hence I do nothing with self.view property (which calls the viewDidLoad if there is no view yet). In viewDidLoad I call [tableView reloadData] to redraw the cells so that they display the data from my controller created in controller's initializer.
I don't think it's related, but storyboard should be mere scaffold for your view controllers replacing separate nibs with single file.
The statement you quoted has a lot to do with mobile device limitation and design efficiency. It does not relate to Storyboard in particular.
By "instantiating", the documentation meant the -(id)init; call. When this happens, the controller "prepares critical data, but not creates views". This means the controller evaluates a xib file, and constructs an internal hierarchical representation of the views upon init. This step involves only RAM and CPU.
View controller only creates views when it's pushed into the navigation controller, or view transition animation (that's when viewDidLoad kicks in). This is because views are expensive. It involves GPU and Video RAM. Video RAM is much more limited than RAM, it's not efficient to just create views (back buffer in VRAM) when it's not necessary to display.
If you look at your project, you should discover some view controllers being initialized but are not immediately required to show. Without such design, VRAM will drain quickly for no reason.
Suppose I have 2 views. In the first view, I allocate memory to displaying many UI components such as an UILabel, UIImages, etc.
Suppose the user navigates to the next view (via UINavigationController)
Is it OK to deallocate memory assigned to displaying UI components in the first view and then initialize them again once the user goes back to the first view (in viewFirstLoad or the appropriate function)?
It seems to me if you don't do this, then memory will keep on increasing the longer the user uses your app in that particular session.
Is this not allowed? frowned upon? impossible?
It is perfectly normal and in fact, that functionality is built in standard UIViewController - when controller is not displayed its view may be released from memory and you can release all its subviews (e.g. retained through IBOutlet references) in controller's -viewDidUnload method.
When controller needs to display again it reloads its view again.
It depends. Generally, the rule of thumb is that you should free objects that you don't need. If your view is just a view, then yes, I'd release it and all of its subviews. If your view has data that was obtained through a lengthy retrieval process (e.g. a web service call), I'd probably hold onto the data somewhere so that I don't have to go back out and retrieve it when the user goes back to the first view.
To clarify a little: Apple recommends you display data specific to a view in it's -viewDidLoad method, such as setting text on labels. Then, in -viewDidUnload you should release (or nil outlets of) the view objects you setup in -viewDidLoad. It's critical you implement -viewDidLoad, as the base UIViewController code checks that it's subclass actually implements -viewDidLoad before it assumes it can unload the view (and therefore call -viewDidUnload). Failing to implement -viewDidLoad results in the controller thinking it can't recreate your view at a later time, and so it doesn't unload the view from memory. A developer I know experienced this same problem, took forever to track down.
MyViewController.xib has File's Owner class set to MyViewController (a subclass of UIViewController) and File's Owner view connected to a UIView containing some subviews.
OtherViewController.xib has File's Owner class set to UIViewController and File's Owner view connected to an empty UIView.
Is it possible in Interface Builder to embed MyViewController's view inside the view in OtherViewController.xib?
I tried adding an instance of MyViewController into OtherViewController.xib, but I can't drop it inside the view (because it's not a UIView) and I can't get to the view that was associated with MyViewController in MyViewController.xib (only the view controller itself, and nothing it's connected to, makes it over to OtherViewController.xib).
You probably do not want to do this. Follow the warning in the View Controller Programming Guide:
Note: If you want to divide a view hierarchy into multiple subareas and manage each one separately, use generic controller objects (custom objects descending from NSObject) instead of view controller objects to manage each subarea. Then use a single view controller object to manage the generic controller objects.
A UIViewController subclass whose view does not fill the window will not behave as you might expect. It will not receive view controller lifecycle messages, rotation messages, or have its parentView/navigation/tabBarController properties set correctly.
A UITableViewCell should not be the view for a UIViewController. It might have some controller object responsible for managing its behavior (though I suspect this behavior can probably all be contained within the cell view itself) but that controller should not inherit from UIViewController.
This has changed since some of the other answers were posted - you want to take a look at the latest documentation for UIViewController, particularly the guide section "Presenting View Controllers from Other View Controllers" and the class reference guide section "Implementing a Container View Controller". Also, there's a video from WWDC 2012 covering the topic on iTunes: Session 236 - The Evolution of View Controllers on iOS. (The video is very useful, it's not just a general overview.)
You can put it all in one xib. For example, just put it all in your MainWindow.xib.
This can be done programmaticly by adding a reference in OtherViewController to MyViewController. This is perhaps a bit messy and does in some way lead me to ask why you would want to do this but... I will trust that you know what you're doing.
Warning. Because 'Other' will contain a reference to 'My' you will want retain My inside Other. but Do not, I repeat do not retain 'Other' inside of 'My' this kind of cycle will lead to errors.
Good luck and don't forget to vote
ps if you have a little more detail I may be able to help you sort out a better design so that this sort of thing can be avoided :)
At the beginning of my app, I am initializing a UIViewController with a NIB.
At some point, I am removing the view from the screen, then releasing it, so it no longer takes up memory. (At this point I am also saving the state of the view in the UIViewController)
At a later point, I want to recreate the view and bring it back on screen. I will then restore its state. (Using the same UIViewController, not a new one, since it saved the state)
My question, is when I recreate the view, how do I do so from the NIB, or is this not possible?
To me, the obvious remedies are:
Don't save state in the UIViewcontroller (Where does convention dictate that I do save state?)
Don't release the view (maybe just release all of its subviews?)
Don't load my view from a NIB, create programmatically (seems to go against using IB for everything)
Note:
I am not using a UINavigationController, I am handling the swapping of the views myself, since thee are only 2 of them.
If you need that level of control, you dont really want to use IB. Because, as you noted, if remove the view and then later recreate it, you would have to do it in code then anyway. Just design most of the views in IB, then write some code that generates just this view. Then you can call that same method again later to recreate that view when you need it.
You may be able to archive it and later turn it back into an object, but that seems like an inelgant solution. IB does not allow for dynamic creation of controls at runtime, even if they used to exist but don't anymore. There is no shame in leaving IB out of loop for this. In fact it's probably a good idea.
OR
If its a complicated view with a lot of pieces, put the view in it's own nib, and make a view controller for it. Then you can simply instatiate the view controller with the nib name, and add the controllers view as a subview to you main view. Then your view controller handles loading of the nib, and you get to design it in IB. Nothing says the view of a view controller has to take up the entire screen either.
self.otherController = [[OtherController alloc] initWithNibName:#"Other" bundle:nil];
[self.view addSubview:otherController.view];
Don't create the view controller and the view in the same nib file; either create the controller in code or put the view in a separate nib file. If you later nil out your controller's view property, the controller should recreate the view.
But why are you so worried about this? There's already a mechanism to automatically free up the view if you're low on memory: the low memory warning. It will only destroy and recreate the view if you actually need to do so, and it's built in to the system so you don't have to do anything. Remember the saying about premature optimization?