When a UIViewController presents another view controller the simplest way for the presented view controller to dismiss itself when it is done under iOS 5 is to call:
[[self presentingViewController] dismissViewControllerAnimated:YES completion:NULL];
On the other hand, Apple's View Controller Programming Guide says:
When it comes time to dismiss a presented view controller, the preferred approach is to let the presenting view controller dismiss it. In other words, whenever possible, the same view controller that presented the view controller should also take responsibility for dismissing it. Although there are several techniques for notifying the presenting view controller that its presented view controller should be dismissed, the preferred technique is delegation.
This has led some answers here to suggest sticking with making a new protocol and delegation even when only a very simple view controller is being presented. Why is this the documentation's "preferred technique" as opposed to the single line above? Is there any offsetting advantages to downside of a large increase in code written with the delegate/protocol technique? Obviously if there is information from the presented view controller that needs to be passed back to the presenting view controller delegation is a good technique. However, the information is the reason for delegation, not simply cleanly removing the presented view controller from the screen.
The same behavior could by achieved by [self dismissViewControllerAnimated:YES completion:nil] (before iOS 5 [self dismissModalViewControllerAnimated:YES]), as there's always at most one view controller presented (modally) at a time.
However, the point of the delegation pattern is that a single view controller could be presented in different ways such as modally or by being push to the navigation stack. That view controller doesn't know how it was presented (well, it could figure it out, but it should not care). The only thing it is supposed to do is to notify it's parent, i.e. the delegate, that its work is done. The delegate then decides how to remove the view controller (dismiss modal or pop from navigation stack etc.) or that the child should stay because the results of its work are insufficient. So the main idea is reusability of view controllers.
[[self presentingViewController] dismissViewControllerAnimated:YES completion:NULL];
That may be the simplest, but it's often not very useful.
Modal views typically need to return some information to their caller; that's why they're modal. In more traditional SDKs modal windows block their caller until the modal window is dismissed. The result of the modal window is then returned to the caller. E.g.:
int result = ShowModalDialog("Do you want to continue?");
if (result == kYes)
{
doSomething();
}
else
{
return;
}
In UIKit, -presentModalViewController: does not block, so you need some other mechanism for the modal view controller to return information to the presenting view controller. Typically that's done with delegation, though there are other ways (such as having the presenting controller handle the left and right UINavigationBar buttons).
If the modal view controller needs to return a value to its presenting view controller then that's done via delegation, and in that case it makes sense for the presenting controller to dismiss the modal controller after it has received the result. That's the original pattern.
Related
I have two method to jump from one viewcontroller to another
For presentViewController
[self presentModalViewController:view animated:YES];
For pushViewControlle should use
[self.navigationController pushViewController:view animated:YES];
Which Will be best approach ?
Which will cause more memory leak?
Which one is use if Our Design is like
Introduction view (bunch of slides )-> login -> signUp-> HomeActivityScreen-> Then Bunch of tab bar in it
If you use pushViewController you will automatically get a "Back" button in the navigation bar. If you use presentModalViewController you do not, and generally will have to implement your own controls and/or callbacks to handle dismissing the controller.
Conceptually the modal presentation style is generally used for atomic tasks that you cannot navigate away from (i.e. you either complete the task, or you cancel, and you cannot do anything else within the app until you do one or the other).
If you're wondering why have the difference in the first place, I can't say. Personally I think frameworks that provide a unified API for moving from one controller to another (like cocos2d, or Android) make a lot more sense.
You use modal view controllers to focus the user's attention on a Task. When you push, the user is in some kind of navigation flow, but still has the total application at their fingertips. They might decide to go forward or backward, switch to a different tab in the middle, whatever. When they get a modal view controller, they can't do any of that until the task is completed or canceled out of (the modal view is dismissed)
When you present a modal view controller, the system creates a parent-child relationship between the view controller that did the presenting and the view controller that was presented. Specifically, the view controller that did the presenting updates its modalViewController property to point to its presented (child) view controller. Similarly, the presented view controller updates its parentViewController property to point back to the view controller that presented it.
Modal view controllers provide interesting ways to manage the flow of your application. Most commonly, applications use modal view controllers as a temporary interruption in order to obtain key information from the user. However, you can also use modally presented view controllers to implement alternate interfaces for your application at specific times.
So, from my understanding this one is best option.
[self.navigationController pushViewController:view animated:YES];
Apple handles the memory for both of these through Automatic Reference Counting. Although pushing a view controller might require more memory than presenting the same, the allocated memory is released when popping or dismissing the ViewController. ARC releases the said memory if no strong references are made from within the popped ViewController, or in other terms, the ReferenceCount is 0. So care must be taken so that no strong references are retained to the ViewContoller's objects.
Now whether to present or push a ViewController depends solely on your app design. Read this to get an outline on when to present a ViewController, .
They are two approaches to navigate from one view controller to other view controller.
By default:
- pushviewcontroller: you will have a back button to return to last visited page. your viewcontroller is put on top of the navigation stack. Think like a webpage when you navigate between pages.
- presentmodalviewcontroller: you have nothing to comeback to last visited page. It is usually used for: a pop-up or to change to new branch of navigation.
The use of pushviewcontroller & presentmodalviewcontroller does not produce memory leaks.
For your application flow, I suppose that HomeActivitiesScreen is one of viewcontroller in your "bunch of tab bar". If so, create a viewcontroller that contains that tabbar and make it as root of your application (named RootViewController for example). Then:
When application is launched, you show the RootViewController
And immediately, present the modal view to your "introduction pages", then login/signup. This modal view start with a Navigation view controller structure.
When the user is connected, dismiss your modal view, return back to your HomeActivitiesScreen and refresh contain if need.
Like this, you do not keep the reference to your login/signup screen when you do not need.
Here is my issue.
The App I am creating has non-linear navigation.
So I am implementing my own back button and doing my own navigation.
However, I am wondering how I should be presenting the next view.
If my navigation was linear, I could do:
-(IBAction)btnBackPressed:(id)sender
{
[self dismissViewControllerAnimated:YES completion:nil];
}
However that will not work for me since pressing back may not necessarily bring you back to the previous view.
Therefore I am thinking of using for example:
AddTaskViewController *add = [[AddTaskViewController alloc] init];
[self presentViewController:add animated:YES completion:nil];
The reason I am not using Storyboard is because all my UI is made programmatically in code.
The worry I have with this is that I think presentViewController will just push the new view on top of a stack. Thus, if the user presses back, forth, back forth, he will eventually run out of memory.
Given my circumstance that I need non-linear navigation and all my UI is created in code, what should I use to present the next view without wasting memory?
Thanks
If you are still interested in a clean solution using UINavigationController, consider this design.
Situation: Let A and B be types of view controllers. A is the root, and B is a detail view which can push or pop to other B controllers.
Goal: We want to delete any B controllers that are not adjacent to the currently presented view controller, but maintain the hierarchy so we can recreate the views when necessary. Thus, the maximum hierarchy the navigation controller will know about is A--B--B.
Design: Make A the navigation controller's delegate. Give it an array of model objects which represent B controllers enough to recreate the views from them. Add to this array whenever a B controller is pushed, which A will know about from the navigation controller delegate methods. Remove objects from the stack when a B controller is popped.
On pushing a B controller, the A controller will take the navigation controller's view controller stack and (if it exists) remove the B controller directly before the one that was displayed before the push. On popping a B controller, the A controller will (if it exists) recreate the B controller directly before the destination controller and insert it in the stack.
Example: Let's say A has kept track of a hierarchy like this: A--B1--B2--B3--B4. By the system outlined above, the navigation controller only knows about A--B3--B4. When the user pops B4, the A controller will be notified and recreate B2, inserting it before B3. Thus, the new hierarchy is A--B2--B3. When B5 is pushed from B3, B2 is removed to produce A--B3--B5.
I realize this is a fairly complicated system to implement, so I would only recommend it if you had a large number of controllers and required the amenities of UINavigationController. Another solution that occurs to me is UIPageViewController, which allows you to provide view controllers on the fly.
Hope this helps!
Yes you are correct that the user will eventually run out of memory if you keep presenting Modal view controllers using
[self presentViewController:add animated:YES completion:nil];
and
[self dismissViewControllerAnimated:YES completion:nil];
will only dismiss the top most viewController being displayed.
Instead you would be better off building your own container view controller and handle your own navigation. For more information read the "Implementing a Container View Controller" section in the UIViewController Apple documentation.
https://developer.apple.com/library/ios/Documentation/UIKit/Reference/UIViewController_Class/Reference/Reference.html
I have a UINavigationController, in which I push a view controller with a UIModalPresentationPageSheet presentation style.
From within this page sheet's view controller, I present a view controller with UIModalPresentationFormSheet style.
When the user hits a Done button the the form sheet, I want to close out the form sheet and the page sheet.
In the action on the Done button:
-(IBAction)onDone:(id)sender
{
if(self->delegate && [self->delegate respondsToSelector:self->actionSelector])
{
[self->delegate performSelector:self->actionSelector withObject:[NSString stringWithString:self.textView.text]];
}
[self dismissViewControllerAnimated:YES completion:nil];
}
The delegate is the page sheet's view controller, and in the selector, I dismiss the page sheet:
[self dismissViewControllerAnimated:YES completion:nil];
When I run it, I get:
Warning: Attempt to dismiss from view controller <UINavigationController: 0xa9381d0> while a presentation or dismiss is in progress!
I can see why this is happening - because the selector is called before the form view is dismissed, but I don't know the best way around this.
I have tried removing the dismiss in onDone, and call dismiss for both in the selector call (with animated:NO for the form sheet), and it seems to function, but I don't know if this is the way that I should approach fixing it.
Try just calling dismissViewControllerAnimated:completion: on the page sheet. According to Apple's docs:
"If you present several view controllers in succession, thus building a stack of presented view controllers, calling this method on a view controller lower in the stack dismisses its immediate child view controller and all view controllers above that child on the stack. When this happens, only the top-most view is dismissed in an animated fashion; any intermediate view controllers are simply removed from the stack. The top-most view is dismissed using its modal transition style, which may differ from the styles used by other view controllers lower in the stack."
If that's not exactly the behavior you want, then you should use the completion handler argument in dismissViewControllerAnimated:completion: to pass in a block, then dismiss the other view controller from the completion handler, eg:
[formSheetViewController dismissViewControllerAnimated:YES completion:^{
[pageSheetViewController dismissViewControllerAnimated:YES competion:nil];
}
Although really, I think just dismissing the page sheet should do the trick for you. It's still good to understand how completion handlers work. It lets you do some work after the operation is done--very handy.
I've seen this question a couple of times but never really answered. I'm wondering if there is an acceptable/clean way to dismiss all launched view controllers and return to the initial view controller when using storyboards (say from an action within a spawned view controller).
I know how to use delegates, but, I'd prefer to not have my initial view controller implement delegates for every possible spawned view controller. Instead, I'd just like a home button that cleans everything up and returns to the initial view controller from anywhere in the app.
Thoughts?
EDIT: Just for clarity, assume I am NOT using UINavigation Controllers.
EDIT2: Is it possible to just access the methods of the "initial view controller" from anywhere in the app like you might do with the appDelegate?
This should do it at any point. Just stick it in an IBAction and hook it up to a button :)
[self.navigationController popToRootViewController];
I ended up using a singleton. Seems to work quite well.
On the initial load of the initial view controller, I set the view controller as the singleton's property. I can then execute the following code in any action method on any view controller in the app to dismiss all view controllers and return to the initial view controller.
initialViewControllerManager *ivcManager = [initialViewControllerManager sharedInstance];
LPViewController *ivc = ivcManager.initalViewController;
[ivc dismissModalViewControllerAnimated:YES];
May not be the "right" answer, but, seems to work. And, given the complexity of my scenes, relying exclusively on UINavigationControllers would be very complicated.
I have the following environment:
root view controller is UINavigationController
a number of custom UIViewControllers may be pushed on the navigation stack
each of custom controllers may or may not present a modal view controller
I need to be able to programmatically manage the navigation stack (for example - drop all controllers from the navigation stack except the root controller as response to some external event like push notification delivery)
Naive implementation with [navigationController setViewControllers:newControllers animated:animated]; obviously fails if there was a modal view controller presented by any of old controllers ind the stack:
This modal controller stays visible
If a delegation pattern is used for parent<->modal controllers communication (parent is delegate of presented modal view controller) any action in modal view controller results in crash since delegate was already released
So the general problem is that modal controler lifcycle is not bound to the parent controller. My questions are:
Is there a stadard approach for managing this kind of hierarchy and safe navigation stack changes?
If NO than what would be a best custom implementation? I'm seeing two general approaches - one is to explicitly dismiss/unlink all modal contrellers in the code changing the navigation stack, the other is to add logic to parent view contollers to manage modal controllers lifecycle directly.
There is no standard approach because this behaviour is discouraged by the HIG. Even in the event of push notifications, you're not supposed to modify the existing stack except through pushes, pops, and pop-to-root. However, what you're asking is completely possible.
You have several options, but the best is probably notifications. Use NSNotificationCenter in your app delegate to let any interested view controller's know that you're about to pop to your root view controller. In each of your modal view controllers, register for this notification name and dismiss yourself when notified. After dismissing your modals, you can just use popToRootViewController and avoid messiness with modifying the stack.
Take a look at TweetBot and see how they handle push notifications. They do a pretty good job, I believe, and they just present a new modal view controller. You can do this (nested modal presentations), so experiment around and see what you can do without jarring the user.
Check this method:
http://developer.apple.com/library/ios/documentation/uikit/reference/UINavigationController_Class/Reference/Reference.html#//apple_ref/occ/instm/UINavigationController/popToRootViewControllerAnimated:
Also, modal controllers are modal for a good reason - to draw user’s attention on one task or unit of work or whatever your app does. So, if you want to programatically hide it and return to some other controller in navigation stack, it’s kind of obvious you need to deal with the modal controller first.
call [self dismissModalViewControllerAnimated:YES]; from -(void)viewDidUnload method of the viewcontroller.