PROPER way of creating Custom Segue

久未见 提交于 2019-12-24 04:15:10

问题


Now, yes, there are hundreds of questions (and answers) of how to perform custom segues. However, and I'm no exaggerating, ALL of these answers are wrong (all 50+ I've seen)! Sorry, this might sound harsh, but the truth is, NONE of the suggested answers gives the same (correct) result as Apples built in transitions do (vertical cover etc.).

To be more specific, this is the result that's expected (confirmed with logs):

  1. Segue begins (adds view to hierarchy, invokes viewWillAppear on destinationVC and viewWillDisappear on sourceVC and starts animation).
  2. animation is performed for the whole duration
  3. Segue ends (animation finished, sets the destinationVC as the current VC, either on stack or modally presented. Invokes viewDidAppear on destinationVC and viewDidDisappear on sourceVC).

In short: invoke viewWillAppear/Disappear -> animate transition -> invoke viewDidAppear/Disappear

Using apples built-in segues, this is the expected behavior but somehow not a single soul except me have had issues with this. A lot of versions even add the destination-view as subview first, animates it then removes it again and calls

[srcVC presentModalViewController:destVC animated:NO];

or

[srcVC.navigationController pushViewController:destVC animated:NO];

causing the view-events to be sent in all kinds of random order (same issue with CoreAnimations).

In my case, all I really want is the "Vertical Cover"-transition reverted (top to bottom), with all other events sent EXACTLY as expected (shown above).

So, am I just supposed to live with all kinds of ugly workarounds (doing my "tasks" in hard-coded methods called whenever I need them to etc.), or is there some hidden proper way of doing this in a reusable manner?

Funny thing: Even apple suggest that you do it the "wrong" way, making it seem like the right way but with inconsistent outcome compared to their own ways… So my best guess is that apple do this under the hood, and forgot to give enough flexibility for clients to perform the same operations (big flaw in other words), or that I'm just on some bad trip and see some issue that doesn't exist…


回答1:


Okay, this might not be a true answer of how to solve it for custom segues (subclassing UIStoryboardSegue), but it does solve the general issue!

After some casual reading about new features, I stumbled upon a new way to do custom transitions between ViewControllers introduced in iOS7 called nothing more than "Custom Transitions" i guess! Read about it here and here, or video from WWDC here.

I've just dipped my toes, but basically it is a new, closer to the system way of doing transitions and allows for better control = better looking transitions. After glancing at the example provided by the blog I referenced (git found here) I can confirm that FINALLY, we are able to do transitions which behave as ONE EXPECTS THEM TO with events fired at the expected occasions!

Since I'm just reading about it I can't give a thorough explanation yet, but check out the links :)

Note: This is maybe not supposed to completely replace custom segues, but can be used in a similar fashion (check examples) so if you need that little extra fancy transition, this is definitely the way to go by the looks of it! Basically you setup segues in the storyboard, and hook up the correct transition-delegates in the prepareForSegue:-method.



来源:https://stackoverflow.com/questions/21311374/proper-way-of-creating-custom-segue

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!