Presentation and Dismissal of Modal View Controllers in iOS: Practice and Principle Analysis

Fundamental Mechanisms of Modal View Controllers

In iOS development, modal view controllers represent a common user interface pattern that allows presentation of a new view controller on top of the current one, typically used for displaying temporary content or obtaining user input. The UIKit framework provides standard implementation of this functionality through the presentModalViewController:animated: and dismissModalViewControllerAnimated: methods.

Analysis of Common Error Scenarios

A frequent issue developers encounter when working with modal view controllers is attempting to sequentially call presentation and dismissal methods on the same view controller, with only the presentation operation taking effect. The following represents a typical erroneous example:

NSLog(@"%@", blue.modalViewController);
[blue presentModalViewController:red animated:YES];
NSLog(@"%@", blue.modalViewController);
[blue dismissModalViewControllerAnimated:YES];
NSLog(@"%@", blue.modalViewController);

This code expects to first present the red view controller and then immediately dismiss it, but the actual result is that the red view controller is presented but not dismissed. The log output shows that the first NSLog outputs null, while the subsequent two outputs display the memory address of the red view controller, indicating that the modal view controller has been successfully presented but not dismissed.

Root Cause Analysis

The core issue lies in misunderstanding the target object for the dismissModalViewControllerAnimated: method invocation. In UIKit's design, the dismissal operation of a modal view controller should be initiated by the presented view controller (the modal view controller itself), not by the parent view controller that presented it.

The correct invocation approach should be:

[blue presentModalViewController:red animated:YES];
[red dismissModalViewControllerAnimated:YES];

Or, more appropriately for practical application scenarios, calling from within the presented view controller:

[self dismissModalViewControllerAnimated:YES];

This design pattern embodies the principle of separation of responsibilities in iOS development: the entity responsible for presentation is not necessarily responsible for dismissal; the presented view controller typically has better knowledge of when it should dismiss itself.

Impact of View Controller Lifecycle

Another important consideration is the view controller lifecycle. If the aforementioned code is placed within the applicationDidFinishLaunching: method, a situation may occur where all logs output null. This happens because during the early stages of application launch, view controllers instantiated from Interface Builder may not yet be properly linked to the application, resulting in the blue and red variables remaining nil.

The correct approach is to place modal view controller presentation logic within view controller lifecycle methods such as viewDidLoad or viewDidAppear:, ensuring that view controllers are fully initialized and ready to handle user interface operations.

Consideration of Animation Timing

Even with the correct invocation target, attempting to immediately call the dismissal method before the presentation animation has completed may cause the operation to fail. UIKit's animation system requires time to execute view transitions, and attempting to initiate another animation while one is in progress may be ignored by the system or lead to unpredictable behavior.

To address this issue, consider using completion blocks or delegate patterns to ensure operations execute in the correct sequence:

[blue presentModalViewController:red animated:YES completion:^{
    // Execute dismissal after presentation animation completes
    [red dismissModalViewControllerAnimated:YES];
}];

Note: The above code uses syntax from modern iOS APIs, while the code in the original question uses an older API version.

Practical Recommendations and Best Practices

Based on the above analysis, we propose the following practical recommendations:

1. Clarify Invocation Responsibility: Always call the dismissModalViewControllerAnimated: method on the presented view controller, or use self as the invocation target within the presented view controller.
2. Consider Lifecycle: Ensure modal presentation operations occur only after view controllers are fully initialized, avoiding execution during premature stages of application launch.
3. Handle Animation Timing: If immediate dismissal after presentation is required, consider using completion blocks or delayed execution to ensure proper animation sequencing.
4. Utilize Modern APIs: In applications supporting newer iOS versions, consider using modern APIs such as presentViewController:animated:completion: and dismissViewControllerAnimated:completion:, which offer better flexibility and error handling mechanisms.

Code Refactoring Example

Based on best practices, we can refactor the original code as follows:

// In appropriate method of blue view controller (e.g., viewDidAppear:)
- (void)presentRedViewController {
    RedViewController *redVC = [[RedViewController alloc] init];
    [self presentViewController:redVC animated:YES completion:nil];
}

// In red view controller
- (void)closeSelf {
    [self dismissViewControllerAnimated:YES completion:nil];
}

This refactoring not only resolves the original issue but also improves code maintainability and readability while establishing a foundation for future feature extensions.