Понимание значения переходов UIViewController

Question

Я пытаюсь изучить некоторые новые шаблоны программирования iOS. Я прочитал кучу о переходящих API-интерфейсах UIViewController, добавленных в iOS 7. Они выглядят классно, но также очень тяжелы для того, что кажется более простой задачей.

Рассмотрите этот прецедент: У меня есть пользовательский контроллер контейнера, который управляет «слайдами». Он содержит массив контроллеров представления слайдов, и пользователь может перемещаться вперед и назад, хотя они нажимают кнопку.

я могу осуществить переход на это следующим образом:

private func transitionToViewController(viewController: UIViewController, direction: TransitionDirection = .Forward, animated: Bool = true) { 
    currentViewController.willMove(toParentViewController: nil) 
    addChildViewController(viewController) 
    // ... set up frames, other animation prep ... 
    contentContainerView.addSubview(comingView) 
    UIView.animate(duration: 0.5, animations: { 
     // do the animations 
    }) { (finished) in 
     leavingView.removeFromSuperview() 
     self.currentViewController.removeFromParentViewController() 
     viewController.didMove(toParentViewController: self) 
     // final clean up 
    } 
} 

Как бы новые переходящие API, улучшить это? Насколько я понимаю, эти интерфейсы являются еще более сложными в использовании, если вы свертывают свои собственные контроллеры просмотра контейнера (см custom-container view controller transitions.

ли значение в переходящих API, в основном для интерактивных переходов?

Спасибо за разъяснение

Answer 1

Я думаю, что новый API переход (UIViewControllerTransitioningDelegate и друзья) просто последний шаг в обобщении зрения переходов между контроллерами.

в первых версиях UIKit мы должны были hack the system transition code, чтобы получить какие-либо пользовательские переходы вообще. Спустя годы мы получили контроль над контроллерами, что позволило управлять контроллерами представлений как первоклассными гражданами и create our own interactive transitions. Последним шагом является полнофункциональный общий системный API для любого перехода, о котором вы можете мечтать - это новый API перехода.

Новый API позволяет извлекать переходы в автономные классы. Это, в свою очередь, позволяет, наконец, просто загрузить библиотеку перехода из GitHub и подключить ее к существующему коду в качестве простого делегата перехода. Нет необходимости выводить ваши контроллеры представлений из какого-то определенного суперкласса, не нужно использовать сторонний контейнер контроллера, нет необходимости добавлять расширения к классам UIKit. Теперь переходы, наконец, являются первоклассными гражданами и в UIKit.

Answer 2

Каким образом новые API-интерфейсы перехода улучшат это?

TL; DR Сопровождаемость с помощью инкапсуляции, многократного использования, тестируемости.

Инкапсуляция: Замечания показывают, что существует логика для настройки и состояния для отслеживания с помощью анимации. Вероятно, ваш контроллер просмотра уже достаточно большой; ставя переходную логику где-то в другом месте, каждая деталь меньше и, следовательно, более удобна в обслуживании.

Повторное использование: Что вы будете делать после этого? Настройте переход от перехода к контроллеру, без сомнения. И разве это может быть поворот этой анимации? Довольно вероятно. Таким образом, вы скопируете и вставьте этот код в этот контроллер и, возможно, переверните его там. Теперь у вас две копии. Один экземпляр с использованием переходов будет более удобным. (Также обратите внимание на наличие стручков пользовательских переходов, так как повторное использование и shareability идут рука об руку.)

Тестируемость: код встроен в супертяжелом контроллер представления, как известно, трудно проверить.Пользовательский переход может быть протестирован изолированно без накладных расходов в реальном времени.

Так что для любого кода, который вы собираетесь рассматривать более одного раза, переходные API, вероятно, стоит усилий!