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.
Related
I have been searching all over the web but I can't seem to find the answer to this.
Currently i am using presentViewController to start new ViewControllers, but on certain view controllers i do not dismiss it and call over it. I currently am not using any navigation controllers or anything like that.
I am just worried that if I call the same viewController again via presentViewController, that the same viewController would have 2 running instances.
Is it possible? Or does the iOS framework automatically reuse the idle viewController?
If so, how do i remove the idle view controllers?
Thank you! (I was holding back my question and tried to find it all over the web, so if you can point me in the right direction, it would be very helpful thanks!)
iOS will not reuse your view controller, you can easily check it yourself by printing your view controller in viewDidLoad, you will notice first that viewDidLoad is called every time, and next that all objects have different addresses.
Unless you create thousand of them, or the navigation of your app doesn’t let you come back to an “idle” view controller, I would not say this is an issue though.
I don’t see any clean way to remove a view controller from the memory without calling “dismiss”. You could try to:
- “refresh” your view with new data.
- use something like UIPageViewController if the workflow of your app allows this kind of behaviour.
- rework the navigation so you can dismiss the view before calling another one
Good luck
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.
Just a question I've been pondering, 'traditionally' with modal viewcontrollers the presenting 'parent' view controller should dismiss the presented child.
Apple have stated that the presented child should not self dismiss, thus I tend to set up a delegate protocol just to dismiss a modal view controller.
This seems somewhat overkill,
I was wondering since objective C passes by reference anyway, and there wouldn't be a performance cost, couldn't I just pass a reference of the presenting parent viewcontroller to the modally presented child viewcontroller during instantiation and then make a method call back to the parent to dismiss the child?
Sorry if this is a stupid question...
The reason why you typically setup the delegate/protocol for something like this is that it makes your code much less coupled. Say you wanted to present your view as a popover or subview later? You may not think this is needed but it may as the project grows.
Since the parent controller handles its own modals, subviews, and popovers it knows what to do when a button to exit is pressed (or some other action). The modal (in this case) does not necessarily (and shouldn't!) know how it is being presented, hence it should tell its delegate that and let that controller handle it (popViewController, dismissViewController, removeSubview, etc...). This is a large part of understanding OOP and will help keep your code cleaner.
And no, this is not a stupid question in my opinion.
I'm moving my App to Storyboards and, so far, so good.
However, I've found something that I don't really understand and worries me. I would appreciate if someone can provide some insight on this.
My app uses a normal Navigation Controller. For moving "forward" to new View Controllers, I'm using custom segues; no problems there. However, there's a point in the App where I want to move back to the beginning of the Navigation Stack. I have also configured that "navigation" using a custom segue, for that, I created the segue in Interface Builder by dragging the last view controller to the first one (that already looks weird to me), and I've implemented the custom segue perform method in the following way:
-(void)perform
{
UIViewController *src = (UIViewController *)self.sourceViewController;
UIViewController *dest = (UIViewController *)self.destinationViewController;
[src.navigationController popToRootViewControllerAnimated:NO];
// Custom animation code here
}
... It works great. However, I don't understand why it works. In my mind, the custom segue should be instantiating a new instance of my first view controller and assign it as "dest", but it looks like the segue is smart enough to realize I want to navigate to a previous, existent, instance of a View Controller and, instead of creating a new instance, it assigns to "dest" the existing one.
Does anybody know if using segues in this way is ok? Is it possible that it works by chance but might stop working in the future? Am I wasting memory in anyway as the segue is instantiating a View Controller I'm not going to use?
Thanks a lot in advance!
Am I wasting memory in anyway as the segue is instantiating a View
Controller I'm not going to use?
Yes sir! By using a segue, you effectively allocate a new view controller as it's needed to set the DestinationController property for your custom segue. Test by yourself : add a static counter into your root controller, increment it each time this class is initialized and display it in your view : you'll see it getting incremented every time you pop to root using this trick.
Does anybody know if using segues in this way is ok?
As long as you're effectively wasting memory, no!
There's at least one solution to this problem : release the DestinationController of the segue in your (void)perform implentation. This is really quick to implement, but kinda ugly since you allocate and immediately release your view controller every time... even if it's better than just leaking it, it's not what I'd call a good practice!
To my mind, a better way to achieve what you want would be to not use a segue for that transition, just to use a button or whatever and call popToRootViewController:animated when getting a touch on this button.
Is it possible that it works by chance but might stop working in the
future?
For both the first solution I suggested and the way you're currently doing it, I see absolutely no reason : these are not complicated tweaks, just 'bad-implemented' standard navigation. The second solution is perfectly normal so no worries.
I didn't trust segues much at first (because of crashes if they were not set up correctly and because it wasn't clear to me what was going on under the hood) but I find I am using them more. I still don't exactly "get" what is going on though.
I have a segue between ViewController A and ViewController B with no UINavigationController involved. It does a FlipHorizontal transition, which I like.
When A initiates the segue, what happens to the A instance? I put a log statement in A's viewDidUnload method and it doesn't get called. So is A still lurking around? I'd like to be able to segue back to that same instance of A with all it's vars intact but I haven't been able to figure out how to do that.
As a test, I embedded A in a Nav Controller and tried both a segue and a push to B - and wasn't able to get back to my instance of A. What am I screwing up here?
Remember the difference between the view and the controller. The calling controller is still around, and so is it's view. However, any VIEW that is not on screen can be unloaded by the system. That's when viewDidUnload will get called.
Basically, a controller, like every other object, lives until all references to it are gone. In addition, anything the controller owns is still alive as well. However, while it is still alive, it can get two important messages, which tell it "Get rid of anything you don't need or can rebuild."
One of them is viewDidUnload. The other is didReceiveMemoryWarning.
So, yes, if you have a stack 100 view controllers deep within your NavController, then all 100 view controllers are still around... though some of their views may not be.