Memory leak presentViewController

Question

I am just starting programming on iOS and playing with an attempt to programmatically switch view controllers (i.e. move from one view to another). I know that a view controller that represents the next view controller should be released after another is presented, but I can’t get anything that works. I tried to reject the controller after presenting the next controller, but I still have a memory leak.

So, I have this code in ViewControllerA :

 - (void) switchViews { [self presentViewController:[[ViewControllerB alloc] init] animated:NO completion:nil]; } 

and this is in ViewControllerB :

 - (void) switchViews { [self presentViewController:[[ViewControllerA alloc] init] animated:NO completion:nil]; } 

Buttons in views trigger these events, and basically they just switch from one view to another.

So, how do I switch views back and forth so that a memory leak is not created? And as a note, I use ARC.

Answer 1

Basically, what you do in the code above is creating ViewController A, then ViewControllerB, then another ViewController A, and then another ViewController B, and then another ViewController A, and then another ViewController B.

What you have to do is start with ViewController A, create a ViewController B, and then go back to ViewController A, just close Viewcontroller B.

Read this blog for advice on how to do this in a simple way, which I explained.

Now there is a possibility that using this method can cause some problems, and they are more likely to happen only when you want to do a little more than just close the current ViewController. Apple does state in its docs:

“When it comes time to reject the presented view controller, the preferred approach is to allow the view manager to reject it. In other words, when possible, the same view controller that the view controller introduced should also take responsibility for dismissal. Despite that there are several methods for notifying the presentation view manager that its submitted view controller should be rejected, prefer The final method is delegation.

Now, as @LeoNatan's answer said, this can be bad practice using [self dismissViewControllerAnimated:completion: And the paragraph above, why, I think, he said it was a bad idea.

It is really good practice to learn to do this in both directions. And although my answer is a quick way, it is also a little dirtier.

Answer 2

This should be a good exercise for you, learning Objective-C and design patterns.

Create the ViewControllerBDelegate protocol using the viewControllerBDidClose: method. Create a property in the ViewControllerB called the "delegate". Now, after creating the vcB in vcA, set the delegate object to vcA. Now that you want to return to vcA from vcB, you must notify the delegate that you want to close vcB. vcA will then "fire ViewController: animated:" vcB.

This design pattern is called delegation and represents a two-way “conversation” between an object and its delegate. The delegate "communicates" with the object using the public API, and the object is "corresponded" with its delegate using the delegation protocol.

In the comments, someone recommended rejecting vcB from yourself. This is bad practice and is never recommended. The one who introduced the view controller should be the one who rejected it. As a delegation, you inform the rapporteur that the information submitted is complete and that the facilitator must reject the information presented.