On 12 Apr, 2013, at 8:50 PM, Koen van der Drift <koenvanderdr...@gmail.com>
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 (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
