As we saw in the previous post, your view controller’s view can be released at any time because the device needs memory. One of the things you’ll want to look at in your own code is how you cleanup when when the memory warning occurs.
Here’s an interface for a simple view controller class that embeds a web view. The web view is retained because our controller will need to send it messages:
@interface IFWebViewController : UIViewController
{
UIWebView *webView;
}
// webView is retained because we'll want to do things like this:
// [self.webView loadRequest:[NSURLRequest requestWithURL:newUrl]]
@property (nonatomic, retain) UIWebView *webView;
@end
We setup and retain the web view when the controller’s loadView method is called:
- (void)loadView
{
...
UIView *contentView = [[[UIView alloc] initWithFrame:applicationFrame] autorelease];
self.webView = [[[UIWebView alloc] initWithFrame:CGRectMake(0.0f, 0.0f, applicationFrame.size.width, applicationFrame.size.height - 44.0f)] autorelease];
[self.webView setScalesPageToFit:YES];
[self.webView setDelegate:self];
[contentView addSubview:self.webView];
self.view = contentView;
}
Eventually this method will be called:
- (void)didReceiveMemoryWarning
{
// default behavior is to release the view if it doesn't have a superview.
// remember to clean up anything outside of this view's scope, such as
// data cached in the class instance and other global data.
[super didReceiveMemoryWarning];
}
The view and its sub-views are automatically released and set to nil by the default implementation. But there’s a problem here: the primary consumer of memory in this view has not been released. The web view is still being retained by the controller.
Since UIViewController doesn’t notify you that the view is being freed, you’re left holding onto a web view that you can’t do anything with since it’s not a part of the view hierarchy.
You can’t solve this problem by using a non-retained reference to the view because you’ll be left with stale reference and a crash if you try to use it. Instead, you’ll want to override the method used to set the view in UIViewController:
- (void)releaseSubviews
{
self.webView = nil;
}
- (void)setView:(UIView *)view
{
if (view == nil)
{
NSLog(@"setView: releasing subviews");
[self releaseSubviews];
}
[super setView:view];
}
Of course, you’ll also want to release the retained views when the controller is freed:
- (void)dealloc
{
[self releaseSubviews];
[super dealloc];
}
When you’re debugging this code, make sure to force the memory warnings in the simulator. You can do this easily with the Hardware > Simulate Memory Warning menu item.
I’ve also found it helpful to poke around in the view controllers instance variables to see what’s allocated, check retain counts, etc. Since you can’t access self.view or [self.view superview] without instantiating a new view instance, you’ll need get at the private property using KVC:
- (void)didReceiveMemoryWarning
{
// use this to look at view (without creating an instance with self.view)
NSLog(@"didReceiveMemoryWarning: view = %@, superview = %@", [self valueForKey:@"_view"], [[self valueForKey:@"_view"] superview]);
[super didReceiveMemoryWarning];
}
- (void)viewDidLoad
{
NSLog(@"viewDidLoad: view = %@", self.view);
}
A lot of the complexity in this memory cleanup could be mitigated by UIViewController supporting a unloadView that is called prior to setView:nil in the default didReceiveMemoryWarning. If you agree, feel free to submit a duplicate bug on Radar ID# 5834347.
At present, there are no metrics for memory usage on the device, so there’s a bit of guesswork in determining how much of your view controller’s object graph should be released. If in doubt, free your data and let it be re-instantiated lazily. You’ll find the overall user experience to be much better.
Note: If Apple feels that sharing this information is outside of the bounds of the NDA, I’ll be forced to remove this post. So just add this to your ever growing collection of furbo PDF files.