UINavigationController: Release ViewController's memory when popped - iphone

I have seen a few posts on this subject here on SO, but no definitive answers. Here is my problem.
I have a UINavigationController which I use as a gallery. On the first controller I load up a bunch of remote images. This increases my memory size, but not by that much. When clicking an image, it will push on another viewController which has images for the gallery just clicked. This might load in another 1MB or more of data from those images.
The problem here is that a user might browse any number of these galleries. Since when I pop the viewController, that memory is not released I start to get too much memory usage in my app when the users continues to browse the galleries.
Is there any way that I can release this memory when I pop my viewController? Perhaps in my viewDidDisappear: method? If so, what would I release? And how can I create it again? I tried this to a point, such as releasing my view, but I get crashes.
Any insight into this issue?
PhotosGalleryiPad *gallery = [[PhotosGalleryiPad alloc] init];
gallery.items = self.items;
gallery.asset = self.currentAsset;
[self.navigationController pushViewController:gallery animated:YES];
[gallery release];

You normally release any memory in the dealloc method of the view controller that gets popped off the stack.
However, if you're talking about images and you loaded them with [UIImage imageNamed:] then UIKit may be caching them. Try faking a memory warning in the simulator (from the Hardware menu) and see if that unloads these cached images.
You can also do a heapshot analysis in Instruments. Mark the heap before loading the view controller, mark it again after closing the view controller, and see which objects stick around.

Where, exactly, are you retaining these gallery images?
Let me take a guess that gallery.items is a mutable collection (possibly an array) holding the images. As the user visits new galleries, more images are added to this array. From view controller to view controller, you are passing a pointer to this array:
gallery.items = self.items;
So, when you pop the view controller, you are still left with the same, enlarged, array. The issue, then, is how to cull this array of the newly added images when you pop a view controller.
Rather than passing a pointer, you could make a shallow copy of the collection. If it's a mutable array, you could do as follows:
gallery.items = [self.items mutableCopyWithZone:nil];
Then, when a view controller is popped, its items array is released. The objects added by the popped view controller are released, but the old objects are still retained in the previous view controller's items array.
(I'm just taking a guess. If I'm wrong, it would be helpful if you explained where you're retaining these images.)

If you are "popping" views onto the foreground like this:
infoScreen = [[[infoScreen alloc] initWithNibName:#"InfoScreen" bundle:nil] autorelease];
infoScreen.view.center = CGPointMake(self.view.bounds.size.width / 2, self.view.bounds.size.height / 2);
[self.view sendSubviewToBack:self.view];
Then you would do [infoScreen release];
to release/free the view from memory.
Remember anything you alloc, or retain (there are other situations too but i forget them off hand) you need to release.

Related

How to release a view when it's not visible in a tabbar controller?

I have a simple app with a tabbar navigation interface.
It has three view (A, B and C) and a modal view. Each view has its own view controller and nib . They are all designed and connected in the interface builder.
I'd like to release views which are not visible.
Tried release and nil them when another view appears such as
[[[self.navigationController.viewControllers objectAtIndex:0] view] release];
[[self.navigationController.viewControllers objectAtIndex:0] view] = nil;
etc.
It doesn't cause any issues but when I run instruments it does not make any difference. I don't see any drop in memory usage
I would appreciate your help
as #Daryl Teo wrote you should release and recreate in viewWillDis/Appear and (thats why I write this answer) you have a method called didReceiveMemoryWarning, use it!
You can simply log out whenever it gets called and test it with the Simulator included memory warning test function.
Simply open a tab, open another tab and call that test function. Your debug console should print out the log. If not you should double check if you have released all objects maybe someone is over-retained (which again should be released in viewWillDisappear).
The drop in memory usage might not be significant, depending on what the released viewController holds on to. I sugest you out a NSLog into the 'dealloc' of the viewController to see if it really gets dealloced or if there is some other object still holding on to it. Remember that release won't free the memory, it will only do so (by calling dealloc) if the objects retain count reached 0.
You don't want to do this. Let the TabBarController handle your view controllers for you. (It will already retain your viewController internally so whatever you do will only make retain count go out of sync)
You may be able to make it more memory efficient if you release objects in viewWillDisappear. Then rebuild the data again in viewWillAppear.

iPhone How To Save View States

I have been developing iphone applications for around 3months now and theres a few things that stump me and i don't really have an idea how to work round them.
I have a navigation controller controlling the views in my application however every screen that is loaded, used then pushed back loses all the information as it seems to be reinstantiated... I believe this is a possible memory management issue?
But how to i create an app that navigates and retains all information in its views until the application is closed.
Thanks :)
Possible you didn't keep a reference to the view controller, the issue is for UIVIewController not to be released.
Make the view controller an ivar you will instanciate only one time when you push it on stack.
// in .h
MyViewController *mVC;
// in .m
// maybe when the user selects a row in a tableview
if(mVC == nil) {
// first time use, alloc/init
mVC = [[MyViewController ....];
}
// then push on the stack
[self.navigationController ....];
Of course don't forget to release it later.
In this part:
MyViewController *myViewController=[MyViewController alloc] initWithNibName:#"myView" bundle:nil];
[[self navigationController] pushViewController:myViewController animated:YES];
[myViewController release];
You will probably have something like this... Instead, make your myViewController a class's property so you have a reference to it. And drop the [myViewController release]; statement.
Possibly your app is receiving a didReceiveMemoryWarning.
In such cases, when the super class is called, the framework does memory cleaning by unloading all the views that are not currently displayed. This could explain the behavior you are seeing.
To check it further, override didReceiveMemoryWarning in one of your view controllers or applicationDidReceiveMemoryWarning in your app delegate, and put a breakpoint in it. Don't forget to call [super...] appropriately, otherwise pretty soon your app will be killed. What you should see in this way is that the views do not disappear before hitting the breakpoint, and do disappear after that.
If the hypothesis is correct, you should find a way to save the state of your view in viewDidUnload and restore it in viewDidLoad. Look also at didReceiveMemoryWarning reference.
Try to save data in NSUserDefaults it its small or use plist or it its too small like 5-10 objects save in in some variable in appDelegate, and if its too large use sqlite and for saving something like images of files like xml use Document directory
The UINavigationController works like a stack: you push and pop UIViewControllers on it. That means when a UIViewController get popped, it will have its retain count decremented by 1, and if no other object holds a reference to it, it will be deallocated. You can avoid the UIViewControllers getting dealloced by keeping a reference to them yourself by calling -retain on the objects, for instance in your appDelegate.
You can use NSUserDefaults to save the states of the UIControls in the view.
So whenever u r loading a view, set the values to the controls so that it looks like it resume from the place where we left.

UINavigationController memory does not decrease when pop a controller

I have a navigation controller-based application with 5 view controller inside. When I push a view controller I allocate some memory and when I go back with popViewController my delloc() method is correctly called. I'm sure that the dealloc is called in the right way for every view controller I push and pop.
Nevertheless when I run the application with Instruments (Start with performance tools -> Object allocations, Leaks) there is a strange behavior for me.
When a view controller is pop the memory usage does not decrease, to be exact it does not decrease as expected:
when I start the application it use 950 KB, then I push the first view controller and the memory usage increase up to 1,56MB, finally I pop the view controller and the memory usage is now 1,55MB.
Is this behavior right?? I'm sure that every dealloc method is correctly called whenever I pop a view and the Leaks instrument does not show any memory leak.
I guess that the operating system is "retaining" in some way the view so that to second time I push the same view controller the loading process is much more fast...
Could someone confirm that this behavior is right?
Thanks
See this Screenshot from Instruments
This is as expected. The memory handling rules of "you are only accountable for objects you did alloc, copy etc. on" applies here as well.
When you push stuff on to the navigationController I assume you do it like this:
MyController *myCon = [[MyController alloc] init];
[self.navigationController pushViewController:myCon animated:YES];
[myCon release]; //You have alloc and release.
The navigationController is often handling a hierarchy where a user drills down a data set, and up again. By holding onto your controllers when memory is plenty is the navigationControllers way of saving having to instantiate the controller again 5 sec. later when the user taps "back". You can see this because dealloc never gets called, but viewWillAppear and viewDidAppear are called when you back up.
If memory is lacking the navigationController will start to release controllers on its stack.
But! make sure that going back and forward does not result in the viewControllers being instantiated again and again, this will make the memory footprint grow and there is a leak.
The navigationController should notice that it already has the viewController in its stack and simply display it.
You should be able to move through all the views and if they "fit" in memory, the app should never increase its memory footprint from here on out.

how to know whether dealloc is getting called or not in iphone sdk?

i am using UIviewcontroller subclasses. In my main view i have 3 buttons, each button will load a different nib. and each new nib is having one back button to come back to main view.
when i click one the back button of any view to move to the main view the dealloc of that view is not getting called? i didnt understood this.
can anyone explain when those views dealloc will be called?
if the dealloc method hasn't been called, it means that your retained your viewController object by hands. for example, in this case dealloc will not be called after clicking back button to return
MyViewController *controller = [[MyViewController alloc] init];
[self.navigationController pushViewController:controller animated:YES];
You should add
[controller release];
to this code to be sure that your instance of viewController will be deallocated. If you are absolutely sure, that you had sent equal number of alloc(or any message that increases object's retainCount) and release messages for your object and dealloc method doesn't be called anyway, it will be more complex. I hope that this answer will help. If you will find that your situation is "more complex", post a comment, then I'll try to explain with more details.
I too would like to dive deeper into understanding memory management details (below surface level) where it comes to controllers being pushed on and off of the stack. I built my framework from the text, "Beginning iPhone 3 Development" by Mark and LaMarche, but that text effectively re-uses sub-controllers and their dealloc methods never get called.
I have noticed that repeated use of a sub-controller with a NIB containing a UIWebView that calls Google's web directions url ... eventually results in a memory warning and my data is lost. This involves repeated "reuse" of the sub-controller.
If you can point me as well to in depth text that goes into nav controller and sub view memory management, that would be excellent.

iPhone: Reusing UIViewControllers in order to save memory

what are best pratices to reuse UIViewControllers? In many apps (including Apple's own examples: e.g. SQLiteBooks), UIViewControllers are allocated and initialized everytime, a UIViewController is pushed to the stack. This increases the use of memory with every new controller, because the objects stay in memory and aren't used again.
How to make it better?
This increases the use of memory with
every new controller, because the
objects stays in the memory and aren't
used again.
It should be released when the stack is popped though, as long as you have not got something else holding on to it. Check your dealloc methods are getting called.
Also if it is pushed to the stack, then you need to keep it around at least until it is popped (which automatically happens if you follow the standard patterns). So it is used again.
So following the standard pattern should already keep your memory usage as small as you can get away with.
This is what I do when creating a new viewcontroller and the memory is released when the view is removed from the window
MyViewController *mvc = [[[MyViewController alloc] initWithNibName:#"MyView" bundle:nil] autorelease];
[[self navigationController] pushViewController:mvc animated:YES];
Do you actually have a memory issue that you are trying to address or is this a case of premature optimization? I would say that unless there is a specific resource issue then the best practice would be to follow the standard view controller patterns.
Put a breakpoint in your view controller's dealloc function, and make sure it is called when you remove the view controller from the window. The memory shouldn't keep building up. If you're properly creating and autoreleasing your controllers (as LostInTransit shows above), the memory for each controller should be released when it is removed.
If you see that dealloc is not getting called, it means that somewhere in the app a reference to the view controller still exists.
Don't forget that a View Controller is not your view.
Views held by a view controller can unload, so view controllers themselves are very lightweight. If you want to keep the footprint really light you could nullify any other data the controller has allocated in viewDidUnload (mostly called when there's a memory warning - it's a 3.0 only thing though).
As noted mostly view controllers will be deallocated when you leave them (hit back) so there aren't generally that any hanging around anyway. But sometimes I find it handy to leave a reference around if I want to re-open that view in the same state the user left it (does not work between app launches).