Purging UIViewController - ios

I have a stack of UIViewControllers currently, each is a modal ViewController presented over the previous one. My problem is that I do not need a stack of UIViewControllers, I only need the last one. So when a new UIViewControllersis presented, its parent should be purged, deleted completely from memory. My app will never need those viewcontrollers again.
I have read this: http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/ViewLoadingandUnloading/ViewLoadingandUnloading.html
But this pattern only cares with memory freeing if the app gets a memory warning. And doesn't purge viewcontrollers, only their content. I would like to do it in a more manual manner... Is this possible, or it is not a common practice in iOS, and I should rely only on memory warning messages.

The easiest way is to avoid creating the stack in the first place. Instead of presenting new modal controllers over existing ones, have your root controller dismiss the existing one first and present each new one.

I might have found a nice solution. One should use a UINavigationController, and manage its viewContollers property (which is the stack of UIViewControllers) manually. After (or before) the new UIViewController loaded, you can delete the old UIViewController from the stack, and thus purge it from the memory.
This post helped:
How can I pop a view from a UINavigationController and replace it with another in one operation?
This way you can make a program flow, where only when UIViewController is in the memory at a time, and you replace them when you need a new UIViewController.

Related

Viewcontroller stack understanding issue

I got some serious problems understanding the viewcontroller stack.
When will my app use a stack to save the previous viewcontrollers? Only if I use a navigation viewcontroller or anytime I use normal viewcontrollers and segue modally between them?
So I was just wondering if I use some sort of chained routine for example, like going from vc 1 to vc 2 and from vc 2 back to vc 1. No navigation controller, just modal segues, no unwinding.
Does my app got performance issues because of a stack (which will grow everytime I go around) or doesn't it make any difference?
----updated
So basicly this is my problem. If I went through the routine of the app, the views get stacked everytime I do a transtition.
UINavigationController will retain any controller you push onto it's navigation stack until you pop it back off.
Any UIViewController will retain a controller it presents modally until that child controller is dismissed.
In either case every controller will at a minimum consume some memory until you remove it. Apps which construct ever expanding stacks of controllers are likely to encounter a number of issues including:
you will eventually run out of memory, how fast depends on how much memory each controller uses.
you may see unexpected side effects if many controllers in the background react to the same event.
users may become confused if they change state in an instance of controller 'A', push an instance of controller 'B' on top of it, and then "return" to a second instance of 'A' added to the top of the state. Since they're looking at a new controller and view whatever selection, scroll position, user input, or other state they set on the previous instance may be lost.
developers, including you, may come to dread touching this app.
I suspect that everyone will have a better experience if you view controller management matches whatever visual metaphor you are presenting to the user.

Should I use a navigation controller in this scenario?

so I am building a simple chat app. I will have a login screen, register and later on a UITableViewController so show the friend list. I'm not sure if I should use a UINavigationController for this or just stick to UIViewControllers. Below are two images for the potential setups.:
and:
I'm just wondering is it generally better practice to use a navigation controller? I am also a little confused about what happens to a view controller when it is popped. Does [self.navigationController popViewControllerAnimated:YES]; keep the view controller in the memory to be accessed again later or is a new one created each time? The same question for [self dismissViewControllerAnimated:YES completion:nil], is this destroying the controller or storing it for use later? Thanks
I'll give you my opinion about when to use a navigation controller.
If your app need to present its content in a hierarchical fashion (Master/detail) is pretty common to use a UINavigationController.
If you need to present some content that is not strictly related with the presenting content you can present it using a new view controller on top of it.
Regarding the memory, as soon as you don't keep any reference to the controllers either presented or pushed once remove (popped / dismissed) you loose any reference to them so no space used in memory
I think you will stick to the UINavigationViewController. Simply because the login and registration are belonged to your user management. From the UX standpoints, it's better to use Modal if the scene you are going to present is somehow irrelevant to the current scene. Therefore, go with UINavigationViewController for your situation.
The second question is related to memory management. It's kind of like the reference counting. If you have something to reference the UIViewController, its reference counting won't drop to zero which mean the system won't clean this up. So, you still have way to get then. If you just simply pop then up or dismiss it without referencing it. The reference counting will become zero and the system will clean it.
Note: If you want to simply display a view controller which doesn't need hierarchical navigation or a navigation bar then you wouldn't need to use a UINavigationController.
But in this case I would still suggest to use UINavigationController for the simple fact that your use case (Login Flow) can be completely addressed using a navigation flow.
In terms of memory there is now difference. Feel free to use any of them in this concern. Although how these views are presented has difference.

Why ARC is not deallocating memory after popViewController

I'm pushing and popping ViewControllers in UINavigationController.
I'm tracking the memory consumption of my app.
While pushing the new viewController the memory consumption is increasing gradually, but when I'm popping the same ViewController using [self.navigationController popViewControllerAnimated:NO]; the memory consumption does not decrease but the constant.
That particular viewController can be pushed and popped by user many times which can lead the high memory consumption of app in RAM.
What should I do to optimise my memory consumption?
When you dismiss a view controller (or pop it), it will be deallocated if you didn't make any strong pointers to it (that controller is retained by the navigation controller, or the presenting view controller, so you usually don't need to have a pointer to it when you create it and push or present it).
It will be be released if there are no other strong pointers to it
Try to avoid using strong properties for IBOutlets.
Consider reviewing whether you are referencing self in a block. If you do, you risk holding onto the UIViewController reference after you have popped it.
For a more in-depth review of why, check out this answer:
How do I avoid capturing self in blocks when implementing an API?
If your app design allows the user to push and pop the same view controller over and over again, you may want to look at reusing the same view controller and just updating its contents each time it's pushed.
Instead of creating and destroying it over and over, create one, set up its contents and push, when it's popped, keep it around ready to be shown again. Next time it needs to be shown, update its contents and then push it again.
I would like to say, that my last few days were spent on searching the web for my app memory problem. I was switching between 2 UIViewControllers. One of them had a scroll view which kept all subviews on it. It turned out that that UIVC loads a new scroll view without releasing the previous one. It took me several hours to realize it.
What I did was:
Looking for any kind of deadlocks inside the app, then searching for every variable that had a strong atributte and other desperate measures. But what really worked was:
#IBAction func backBB(sender: UIBarButtonItem) {
collectionView.removeFromSuperview()
self.frontView.removeFromSuperview()
eventsPhotos.removeAll(keepCapacity: false)
symbolContainerView.removeFromSuperview()
self.myScrollView.removeFromSuperview()
dismissViewControllerAnimated(true, completion: {})
}
I manually removed some views and contents. I've done it in "Back" button but you can do this in other methods like viewWillDisappear(animated: Bool).
Once I made this, my allocation chart in the developer instruments showed the memory allocation going up and down... And it was solved...
I think you get an error, when you try to pop the view controller because the navigation controller does not have a valid reference to the view controller, as it was released after you pushed it.
Nil the popover on dismiss.
[menuPopup_ dismissPopoverAnimated:YES];
menuPopup_ = nil;
Make sure your viewcontroller (A) has no reference of any other viewcontroller (B) or any object it has. Incase it has then make sure that VC-B is not referencing back VC-A. If it has some reference back to VC-A then make it a weak property. Otherwise strong retain cycle will keep the VC in memory even if its popped.
Another thing is to check wether theres any closure in your VC, check its body if it is referencing any property or method with self then make a Capture list to avoid retain cycle as "Closures are Reference Types"
Check if theres any NSNotification observer you are not releasing
Make a print call in deinit method to check wether its deallocated.
For further understanding on memory management:
https://medium.com/mackmobile/avoiding-retain-cycles-in-swift-7b08d50fe3ef
https://www.youtube.com/watch?v=GIy-qnGLpHU
You should use an unwind segue instead of popping.

Analogue of Cocos2D replaceScene in UIKit

I have used Cocos2D for a few months. I use:
MyCCScene *sceneToRun = [MyCCScene node];
[[CCDirector sharedDirector] replaceScene:sceneToRun];
This loads the new scene, cleans the previous scene from memory, then displays the new scene. Pretty straightforward.
Question:
Is there something similar to this in UIKit?
-Modal segues keep the old ViewController in memory, their purpose is different.
-Push segues work in UINavigationControllers only.
I think the way to go is to implement my own Container ViewController which handles its child ViewControllers and memory the way I want. http://developer.apple.com/library/ios/#documentation/uikit/reference/UIViewController_Class/Reference/Reference.html#//apple_ref/doc/uid/TP40006926-CH3-SW81
But I am not entirely sure. Isn't there a more straightforward method? This looks like a huge overkill for such a simple and obvious thing.
I might have found a nice solution. One should use a UINavigationController, and manage its viewContollers property (which is the stack of UIViewControllers) manually. After (or before) the new UIViewController loaded, you can delete the old UIViewController from the stack, and thus purge it from the memory.
This post helped:
How can I pop a view from a UINavigationController and replace it with another in one operation?
This way you can make a program flow, where only when UIViewController is in the memory at a time, and you replace them when you need a new UIViewController.

Do modal segues create new objects?

Im transitioning from one view controller to another UINavigationController by using a modal segue. Its important for me that this view controller (and its child view controllers) stay in memory so specific references are kept up. Although obviously exactly this not happening. When debugging the viewWillAppear function the rootViewController (viewControllers[0]) reference points to different memory addresses between calls (and contains nil values, my actual problem).
Now there two possibilities which could cause this issue:
The UiNavigationController became destroyed
The rootViewController became destroyed
But to make it really confusing, none of them did happen; neither the UINavigationController nor the rootViewController became destroyed (viewDidUnload not called!).
Edit: Further investigation discovered that the UINavigationController is really recreated for every modal segue. I hope that by maintaining a property i can solve the problem.
I finally ended up by creating my own IBAction functions wich present the controller manually. This works just fine and is coded in less than 5 minutes. One just need to init the controller one time on ViewDidLoad from the storyboard.
Create a strong reference in the main view controller and point your new view controllers to that property. This will keep the view around as long as you need, although this is not recommended for n number of views because it defeats the purpose of a nav controller handling its own creation and removing of views.

Resources