Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a TransitionController type #3

Closed
jverkoey opened this issue Jul 6, 2016 · 2 comments
Closed

Create a TransitionController type #3

jverkoey opened this issue Jul 6, 2016 · 2 comments
Assignees
Milestone

Comments

@jverkoey
Copy link
Contributor

jverkoey commented Jul 6, 2016

Spec: https://material-motion.gitbooks.io/material-motion-starmap/content/specifications/transition_controller.html

This controller publicly conforms to UIViewControllerTransitioningDelegate.

Example use:

viewController.mdm_transitionController.directorClass = [PhotoDirector class];

Class prototype:

MDMTransitionController : NSObject <UIViewControllerTransitioningDelegate>

When mdm_transitionController is accessed, an instance of MDMTransitionController should lazily be created and then assigned to the view controller's transitioningDelegate (if one is not already set). This will allow us to hook in to the iOS view controller transitioning APIs.

@jverkoey
Copy link
Contributor Author

🎊 My diff is ready for review at http://codereview.cc/D1259

@jverkoey
Copy link
Contributor Author

From the discussion at http://codereview.cc/D1259:

Why'd we need to use associated objects?

Primarily because transitioningDelegate is a weak property. Because of this, somebody needs to hold a strong reference to the instance. There are many answers to "who should own this object?" and we've chosen one that appeared to balance convenience with expressivity.

Background

We want our transitionController to customize both the present and dismiss transitions. Using an associated object is a convenient way to ensure that our controller lives at least as long as the controller whose transitions it is customizing.

Some other ways that we'd considered building this API:

  • Having a global transition coordinator singleton that has a lookup table of VC1/VC2 => Director. This has the advantage of allowing transitions to be customized without diving in to view controller code. It has the disadvantage of making the call-site code of present/dismiss less clear as to which director will govern the transition. Note: we can still support this approach even with this associated object API.
  • Making the calling view controller store the transitionController instance. This introduces some overhead into every calling controller in that they must now store a transitionController instance any time they want to present a view controller.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant