코디네이터가 필요한 이유
- iOS에서의 코디네이터는 이 블로그에서 처음 제안된 개념
- 뷰컨이 커지는 문제의 원인 중 하나는 뷰 로직, 비즈니스 로직, 플로우 로직을 모두 담고 있기 때문이라고 지적
- 간단한 앱에서는 뷰컨 내부에서 새로운 뷰컨을 생성하고 present하는 로직이 문제 없음.
- 그러나 앱이 커질수록 뷰컨 내부에서 새로운 뷰컨을 생성하는 로직들이 늘어나고, 이렇게 플로우 로직이 뷰컨 내부에 구현된 상황은 뷰컨의 재사용을 어렵게 만듬.
- 뷰컨은 뷰 객체이고, 유저 플로우 처리는 역할 범위에서 벗어난다고 주장.
코디네이터 개념
- 이전에는 뷰컨이 가장 상위 객체로, 내부에서 그 밑의 모든 객체들을 컨트롤한다고 생각.
- 그러나 Coordinator라는 더욱 상위의 객체가 뷰컨을 가지고 있으며 컨트롤한다면 여러 장점이 있음.
- 코디네이터 패턴을 잘 활용하기 위해서는 코디네이터가 전체 앱을 조종하는 하나의 고수준 객체인 것이 좋음.
- 앱 델리게이트는 AppCoordinator를 가지고, 모든 코디네이터는 그 자식 코디네이터의 배열을 가짐.
- 특히 탭 바 앱처럼 네비게이션 컨트롤러가 여러 개 있는 경우, 각각의 네비게이션 컨트롤러는 자체적으로 동작과 흐름을 관리하기 위한 코디네이터를 가지게 됨.
- 추가적으로, 회원가입이나 콘텐츠 생성과 같은 특정 작업을 위해 자식 코디네이터를 생성할 수 있음.
- 각 코디네이터는 부모 코디네이터에 의해 생성됨.
- 이 패턴은 초기 개발 단계에서 활용하는 것이 좋으며, 인증과 같은 단일 단계 작업에서도 유용하게 사용할 수 있음.
코디네이터 적용의 장점
- 뷰 컨트롤러는 모델과 뷰를 연결하는 본연의 역할에 집중할 수 있음.
- 확장 기능이나 별도로 분리된 앱에서도 더 쉽게 재사용할 수 있으며, 서로 다른 컨텍스트를 관리하기 위한 복잡한 조건문을 사용할 필요가 없음.
- A/B 테스트도 단순히 다른 코디네이터 객체를 생성하고 그것으로 프로세스를 시작하기만 하면 됨.
코디네이터 적용의 단점
- 하나의 화면 생성 시 작성해야 할 코드 양이 많아짐
- 코드 복잡도가 높아짐
- 팀 전체가 동일한 이해도를 가지고 있지 않으면 적용 어려움
코디네이터의 대안
- 상태 기반 네비게이션
- 포인트프리 블로그 참고
- 코디네이터의 단점인 보일러플레이트 코드 / 복잡도를 단순화할 수 있다는 장점이 있다.
- 그러나 뷰컨이 플로우 로직으로부터 완전히 분리되지는 않아서, 플로우 복잡도가 높은 앱에서 쓰이기는 적절하지 않을 수 있다.
- 이 방식에 대해 조금 더 알아보기...
ios 개발자에용