Re: presentViewController completion block usage
Re: presentViewController completion block usage
- Subject: Re: presentViewController completion block usage
- From: Roland King <email@hidden>
- Date: Fri, 12 Apr 2013 21:30:13 +0800
On 12 Apr, 2013, at 8:50 PM, Koen van der Drift <email@hidden> wrote:
> When a modal UIViewController is dismissed, Apple recommends to use the delegate pattern to pass data back to the presenting UIViewController. I am using that and it works just fine. But I was wondering if the same (passing data back) can be achieved using the completion block. Right now, I just set it to nil when showing and dismissing the modalVC:
>
> [self presentViewController: modalVC animated: YES completion: nil];
>
> and
>
> [[self presentingViewController] dismissViewControllerAnimated: YES completion: nil];
>
>
> But even though it is often set to nil, that completion argument isn't there for no reason. So, can it be used to pass values of settings back and forward between the presentingVC and the modalVC? Or is that a misuse of the completion block? And if so, what would be a use of the completion block when presenting and dismissing view controllers?
>
> Thanks,
>
> - Koen.
>
Well that completion block is really there for your view controller to know when the presented view controller has been entirely presented or entirely dismissed (ie the animation is complete) so it can do .. whatever it wants. You can use that to start and stop animations, to clean up some kind of state, that kind of thing. NULL is not an unusual value for it, useful hook when you need it, ofte you don't need it.
I suppose you could use the dismissal one for sending information back to the presenting view controller but it would be rather odd and wouldn't actually help you much. For a start you'd only get the callback after the VC has been entirely dismissed, it's offscreen and the presenting VC is already back in view, which is pretty late, you normally want information from the presented VC to be available to the presenting one right at the start of dismissal so it configures its views and arrives back on screen already showing the current, correct state.
And even if you did use that callback to send information back to the presenting VC, you'd still need a way to access it from the presented VC, so that really would mean turning the delegate pattern around and implementing a protocol on the presented VC which allowed the presenting VC to query it for the information it wanted. So you don't win much.
I suppose that unwind segues are the place in the VC flow where a presenting VC gets told it's just about to come back on-screen, but they are pretty specialized and the delegate patter you're using, for the most part, is the most direct way to move information back to the VC right at the start of dismissal.
Did you have a particular use-case in mind?
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden