I have custom control like tabbar which displays many controllers some of them also have my tabbar with other controllers, so, my app uses lots of memory because every controller is stored in memory. So I want to unload invisible controller, but I not found any method for unloading UIViewController. How can I do it?
PS. I can not use UITabBarController, really can't.
You don't. UIViewControllers don't get unloaded in low memory, just their views do.
This happens in didReceiveMemoryWarning on your own view controllers and gets called automatically when a low memory warning occurs.
Override this and unload anything that can be re-created in viewDidLoad.
Remove the view controllers view from it's superview and release the controller. Job done.
I know it's an old thread but might be usefull for someone.
You can unload viewControllers view by calling:
[viewControllerWhoseViewYouWantToUnload didReceiveMemoryWarning];
Related
My Initial View Controller of the storyboard load another view controller using performSegue:withIdentifier method which in turn loads some other controller using same performSegue:withIdentifier method.
However, neither the initial view controller nor the second view controller are deallocating. They both tend to have a reference count of 1 as seen via instruments.
I need to send user back to first controller when he logs out of application. The only way I have figured so far is to use performSegue:withIdentifier method and send the user back to initial controller.
However, it concerns me that previous controllers will not have been deallocated thus, resulting in re-creation same view controllers.
Since I need to logout a user back to first screen, I want to make sure that all previous view controllers have been deallocated.
When you perform a push or modal segue, it will not (and should not) release the view controller from which you're seguing. It needs to keep it so that when you pop/dismiss back to it, it will still be there. The exception to this rule is when using a split view controller and you use a replace segue. But that's a special case.
If you want to go back to the first scene, if you're using a navigation controller and using only push segues, you can use popToRootViewControllerAnimated. (For iOS 5 targets, I'll always use navigation controller, and hide the navigation bar if I don't want it visible, for that reason. It's convenient to be able to pop back multiple levels. It's cumbersome to achieve the same effect with modal segues.) In iOS 6, you can use an unwind segue, in which you can pop/dismiss back an arbitrary number level of scenes, for example, to return to your initial scene.
Looping with performSegue is not a good idea..
If you have to go back in your VC hierarchy, you should either use a UINavigationController with pushing/poping VCs, or presenting/dismissing a modal VC. You can combine both by modally presenting a UINavigationController.
Prior to iOS 6 A UIViewController will stay alive but its more expensive UIView will be deallocated to save memory. The UIViewController itself is pretty light compared to a UIView.
Since iOS 6 you should according to the documentation override didReceiveMemoryWarning
Docs for UIViewController:
Memory Management
Memory is a critical resource in iOS, and view controllers provide
built-in support for reducing their memory footprint at critical
times. The UIViewController class provides some automatic handling of
low-memory conditions through its didReceiveMemoryWarning method,
which releases unneeded memory.
Prior to iOS 6, when a low-memory warning occurred, the
UIViewController class purged its views if it knew it could reload or
recreate them again later. If this happens, it also calls the
viewWillUnload and viewDidUnload methods to give your code a chance to
relinquish ownership of any objects that are associated with your view
hierarchy, including objects loaded from the nib file, objects created
in your viewDidLoad method, and objects created lazily at runtime and
added to the view hierarchy. On iOS 6, views are never purged and
these methods are never called. If your view controller needs to
perform specific tasks when memory is low, it should override the
didReceiveMemoryWarning method.
As long as you manage you correctly react (depends on the iOS Version) and dealloc the view I see no problems here.
How much memory a view controller eats when it is loaded into the memory?
I have an application where I am planning to keep 4 view controllers in the memory as they are modal on each other and out of them, one view controller is a navigation controller (with 4-5 view controller pushed in stack) presented as modal.
Any suggestions?
A view controller object itself usually needs very little memory unless you use it store large objects like images or caches. What takes a lot of memory is the view that is attached to the view controller. That's why view controllers unload their views when they receive a memory warning and the view is not currently on screen.
So you shouldn't worry. Follow the memory management rules, implement viewDidUnload correctly (release your outlets) and respond to memory warnings appropriately. The view controllers will take care of unloading and reloading their views if needed.
Does presenting a ViewController cause the presented controller to run its viewDidLoad method?
If a view1 is loaded and another is presented. Then something triggers to present view1. Will it run through its viewDidLoad method?
IF not how should this be done? ViewDidAppear?
Building on what Jesse relayed, the viewDidLoad is called when the view is loaded into memory (usually the first time the view controller is ever about to be presented since app launch - simplified, but this will suffice for now).
When you display other view controllers and then come back some how to this original "view1" view controller, unless there was a memory event that jettisoned it from memory, it will NOT call viewDidLoad again.
Instead, it will call the following, in order:
viewWillAppear:
viewDidAppear:
In viewWillAppear:, you have a place to do things "off screen" before your view controller is displayed.
In viewDidAppear:, you can do additional operations that are appropriate for when the view controller's view is already visible. For example, you want to run some little animation that the user will see once the view controller is fully visible.
In both of these methods, make sure you call super's implementation before you do anything. Also, to learn about this lifecycle, set a breakpoint or NSLog() statement in each of these methods (viewDidLoad, viewWillAppear, viewDidAppear) to see when they are called.
There's a concept piece in the Apple docs on View Controllers that is worth the 20 minute read - it'll clear up a lot of this key life cycle information about View Controllers, and these are central to iOS development. See the section "Understanding the View Management LifeCycle" at:
http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/BasicViewControllers/BasicViewControllers.html%23//apple_ref/doc/uid/TP40007457-CH101-SW1
viewDidLoad is only called when the view is loaded into memory. Usually the first time it appears (could be more often if there are memory dumps and etc).
viewDidAppear: is called every time the viewController's view becomes the 'active' view in the window.
I have a tab bar application and i am encountering a strange behaviour....when i toggle the tab bar and reaches into new view controllers sometimes the viewDidLoad of these view controllers are getting called...though viewDidLoad should get called only first time...
can anyone tell...any suggestion??
If there's a low memory warning then a tab bar controller will release all views that are not visible. This means that you can get viewDidLoad called more than once because the view has been unloaded.
Is your app memory-intensive, perhaps to the point that you're receiving memory warning? Though I have not experienced the behavior you're describing, it's possible that due to heavy memory use your unseen views are being released due to a lack of memory. When they're next called into view they would need to be reinitialized, calling viewDidLoad.
Are you sure it's viewDidLoad, not viewWillAppear?
viewDidLoad will only be called once in each UIViewController subclass, so if your layout is like this:
-UITabBarController:
- HappyUIViewController
- SadUIViewController
- ThirdUIViewController
Then viewDidLoad will be called three times. Once for HappyUIViewController, once for SadUiViewController, and so on.
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?