How to use the coordinator pattern in iOS apps

iOS 앱에서 코디네이터 패턴을 사용하면 뷰 컨트롤러에서 Navigation 작업관리가 쉽고 재사용하기 쉽게 만드는 동시에 앱의 Flow를 조정할 수 있다.

뷰 컨트롤러는 앱 Flow에서 자신의 위치를 인식하지 못하거나 애초에 Flow의 일부라는 사실조차 인식하지 못한 채 앱에서 단독으로 독립되어 있을 때 가장 잘 작동한다. 이는 코드를 더 쉽게 테스트하고 추론하는 데 도움이 될 뿐만 아니라 앱의 다른 곳에서 뷰컨트롤러를 더 쉽게 재사용할 수 있게 해준다.

왜 사용해야 하나?

if let vc = storyboard?.instantiateViewController(withIdentifier: "SomeVC") {
    navigationController?.pushViewController(vc, animated: true)
}

위와 같은 종류의 코드에서는 하나의 뷰 컨트롤러가 다른 뷰 컨트롤러에 대해 알고, 생성하고, 구성하고 표시해야 한다. 이로 인해 앱에 결합도가 올라가게 된다. 한 뷰 컨트롤러에서 다른 뷰 컨트롤러의 링크를 하드 코딩했기 때문에 동일한 뷰 컨트롤러를 다양한 위치에서 표시하려면 구성 코드를 복제해야 할 수 있다.

더 안좋은 것은 내비게이션 컨트롤러에게 무엇을 해야 하는지 알려주는 child와 관련이 있다. 첫 번째, View Controller는 부모에게 도달하고 두 번째 ViewController를 push한다고 알려야 한다.

이 문제를 깔끔하게 해결하기 위해 코디네이터 패턴을 사용하면 뷰 컨트롤러를 분리하여 각 뷰 컨트롤러가 어떤 뷰 컨트롤러에서 왔는지, 그 다음은 무엇인지, 심지어 뷰 컨트롤러 Chain이 존재하는지 알 수 없게 된다.

대신, 앱 Flow는 코디네이터를 사용하여 제어되며 View는 코디네이터와 통신한다. 사용자가 스스로 인증하도록 하려면 코디네이터에게 인증 Box를 표시하도록 Request해야 한다. 그러면 그 의미를 파악하고 적절하게 표시할 수 있다.

결과적으로, 뷰 컨트롤러는 어떤 순서로든 사용할 수 있고 필요에 따라 재사용할 수 있다는 것을 알게 된다. 즉, 하드 코딩된 경로가 없어지게 되는 것이다. 왜냐하면 해당 부분은 모두 해당 코디네이터에서 동일한 메서드로 호출할 수 있기 때문이다.