[iOS] Advanced coordinators in iOS 해석 및 정리

Advanced coordinators in iOS

iOS 앱에서 코디네이터 패턴을 적용할 때 마주치는 6가지 문제들에 대한 해답을 찾는다.

1. child coordinators를 언제, 어떻게 사용해야 하는가?

앱이 커지면 부모 코디네이터와 자식 코디네이터를 둘 필요가 있다.

• 자식 코디네이터는 각각 다른 기능(책임)을 맡는다
• 자식 코디네이터 하나의 흐름이 끝났을 때, 부모 코디네이터에게 이를 알리고, 다른 곳으로 흐름을 이어준다.
• 복잡한 앱의 기능을 작게 나누어 재사용이 쉽게 함

child coordinator 예시

class BuyCoordinator: Coordinator {
    var childCoordinators = [Coordinator]()
    var navigationController: UINavigationController

    init(navigationController: UINavigationController) {
        self.navigationController = navigationController
    }

    func start() {
        // we'll add code here
                let vc = BuyViewController.instantiate()
            vc.coordinator = self
            navigationController.pushViewController(vc, animated: true)
    }
}

• 자식 코디네이터가 없었는데 새로 생성한 것이므로, start()메서드 내용을 MainCoordinator의 해당 뷰컨 생성 메서드로부터 가져와서 채운다.

• 그다음 MainCoordinator에서 뷰컨을 직접 만들던 부분을 BuyCoordinator를 만드는 방식으로 바꾼다.

    let child = BuyCoordinator(navigationController: navigationController)
    childCoordinators.append(child)
    child.start()
    child.parentCoordinator = self

• 또한 뷰컨의 coordinator의 타입을 MainCoordinator 에서 BuyCoordinator로 바꾼다.

• 이제 MainCoordinator 와 BuyCoordinator 를 연결해 줄 것이다 - 통신이 되도록

  • BuyCoordinator에 parentCoordinator로 MainCoordinator 를 연결해 준다
  • weak var parentCoordinator: MainCoordinator? - MainCoordinator가 이미 자식 코디네이터를 가지므로 weak로 선언
  • child.parentCoordinator = self 를 추가해 준다.

• 그다음, BuyViewController의 작업이 끝나면 뷰컨에서 코디네이터로 이를 알리도록 해야 한다.

  • 여러 방법(2.에서 개선할 것임) 이 있지만 여기서는 viewDidDisappear() 를 사용한다.

    override func viewDidDisappear(_ animated: Bool) {
      super.viewDidDisappear(animated)
      coordinator?.didFinishBuying()
    }

  • 위에서 호출하는 didFinishBuying() 을 BuyCoordinator에 구현한다.

    • 처리 방식은 앱 흐름에 따라 달라지겠지만 여기서는 특별한 동작이 필요하지 않은 경우로 가정하고 구현한다.

      func didFinishBuying() {
        parentCoordinator?.childDidFinish(self)
      }

  • 위에서 호출하는 childDidFinish()를 MainCoordinator에 구현한다.

    • === 연산자를 사용한다 - 배열 내에 자식 코디네이터가 있는지 확인하기 위해. 클래스에만 사용 가능

      func childDidFinish(_ child: Coordinator?) {
        for (index, coordinator) in childCoordinators.enumerated() {
            if coordinator === child {
                childCoordinators.remove(at: index)
                break
            }
        }
      }

  • 클래스에서만 사용 가능함을 보장하기 위해 Coordinator 프로토콜이 AnyObject를 준수하도록 하면 좋다.

      protocol Coordinator: AnyObject { ... }

2. navigation controller로부터 뒤로 이동하는 것을 어떻게 처리하는가?

• 메인 코디네이터가 내비게이션 컨트롤러와의 상호작용을 직접적으로 감지하도록 만든다.

  • 기존 코드에서 뷰컨의 viewDidDisappear() 와 코디네이터의 didFinishBuying() 을 주석 처리한다. - 더 개선된 방식으로 바꿀 것이기 때문

• 메인 코디네이터가 NSObject를 상속하도록 한 다음, UINavigationControllerDelegate 프로토콜을 준수하도록 한다. (NSObject를 상속해야만 UINavigationControllerDelegate 프로토콜을 채택할 수 있기 때문)

  • class MainCoordinator: NSObject, Coordinator, UINavigationControllerDelegate

• 그다음, 메인 코디네이터를 내비게이션 컨트롤러의 delegate로 지정하여

  • 뷰컨트롤러가 보여질 때마다 내비게이션 컨트롤러가 메인 코디네이터에게 알려 주도록 하는 작업.
  • start()에 navigationController.delegate = self 를 추가한다

• 뒤로 이동하기 위한 동작을 구현할 수 있다. - UINavigationControllerDelegate의 didShow()를 구현한다

  • MainCoordinator에 다음과 같이 구현한다:

  • 이전에 어떤 뷰컨으로부터 이동하는지 읽어낸다

  • 이전 뷰컨이 아직 navigationStack에 존재한다면 : pop이 아닌 push동작으로 인식된 것임

    • 아무 조치도 할 필요 없다 (return)

  • 이전 뷰컨이 navigationStack에 존재하지 않는다면 : pop된 것이 맞음

    • pop된 뷰컨의 coordinator를 읽어와서 childCoordinators에서 삭제해 줘야 함

    // MainCoordinator
    func navigationController(_ navigationController: UINavigationController, didShow viewController: UIViewController, animated: Bool) {
      // 어떤 뷰컨으로부터 이동하는 것인지 조회 Read the view controller we’re moving from.
      guard let fromViewController = navigationController.transitionCoordinator?.viewController(forKey: .from) else {
          return
      }
    
      // Check whether our view controller array already contains that view controller. 
          // 우리의 VC 배열에 해당 뷰컨이 존재하는지 확인
      // If it does it means we’re pushing a different view controller on top rather than popping it, so exit.
          // 만약 존재한다면 그것은 pop이 아닌 최상위의 다른 뷰컨을 push하려는 것임을 의미하므로, 종료함
      if navigationController.viewControllers.contains(fromViewController) {
          return
      }
    
          // 뷰컨을 pop한다는 의미이므로, 그것이 BuyViewController인지 확인
      // We’re still here – it means we’re popping the view controller, so we can check whether it’s a buy view controller 
      if let buyViewController = fromViewController as? BuyViewController {
          // BuyViewController가 맞다면 그것을 지운다
          // We're popping a buy view controller; end its coordinator
          childDidFinish(buyViewController.coordinator)
      }
    }

뒤로 가는 작업이 까다로운 이유는 Coordinator에 의해 발동되지 않기 때문이다. 다행히 UINavigationControllerDelegate 프로토콜로 이러한 이벤트를 깔끔하게 모니터링 할 수 있다.

3. view controller들 사이에 데이터를 어떻게 전달하는가?

뷰 컨트롤러 사이에 데이터를 전달하는 것은 코디네이터가 있을 때 더 어려워 보이지만, 실제로는 코디네이터 사용은 뷰 컨트롤러 사이에 hard link를 생성하지 않는 것이 보장되는 좋은 방법이다.

노트 : 이후 과정을 따라하기 위해서는 원래의 Coordinators 프로젝트로 되돌리십시오.

뷰컨트롤러에 저장할 데이터 선언

// BuyViewController에 추가
var selectedProduct = 0

이 데이터가 뷰컨이 생성될 때 제공되어야 한다면, 이 뷰컨을 생성하는 코디네이터에서 매개변수로 넘겨주어야 한다.

MainCoordinator의 뷰컨 생성 메서드 수정

func buySubscription(to productType: Int) {
    let vc = BuyViewController.instantiate()
    vc.selectedProduct = productType // 매개변수로 받아와서 지정
    vc.coordinator = self
    navigationController.pushViewController(vc, animated: true)
}

뷰컨에서 코디네이터로 작업을 넘길 때 해당 데이터를 전달

// BuyViewController의 메서드
@IBAction func buyTapped(_ sender: Any) {
    coordinator?.buySubscription(to: product.selectedSegmentIndex)
}

🗣 즉 A뷰컨트롤러에서 B뷰컨트롤러로 데이터를 넘길 때, 1. A뷰컨트롤러 → A뷰컨트롤러의 코디네이터 → 메인 코디네이터 에게 매개변수를 통해 데이터를 전달한다. 2. 메인 코디네이터에서 그 데이터를 가지고 다른 뷰컨트롤러의 프로퍼티를 설정하거나, 3. 메인 코디네이터 → B뷰컨트롤러의 코디네이터 → B뷰컨트롤러 로 데이터를 직접 전달해 주어야 한다.

중요한 점은,

뷰 컨트롤러는 다른 뷰 컨트롤러가 존재한다는 것을 몰라야 한다.

뷰컨은 코디네이터에게 ‘어디로든 갈 수 있는' 데이터를 전달한다 - 그 데이터는 네트워크 요청을 보내거나, 다른 뷰컨을 보여주거나, 또는 다른 어떤 작업을 위한 것이다.

코디네이터는 목적지를 파악하게 해 준다 - 받고 있는 값(매개변수)이 무엇을 의미하는지를 결정한다.

4. coordinator에 tab bar controller를 어떻게 사용하는가?

앱의 기능을 명확하게 나누어 보여주기 위한 방법으로 tab bar controller를 일반적으로 많이 사용한다. 코디네이터는 tab bar controller에도 잘 동작한다 - 코디네이터는 그것들을 함께 잘 묶어둔다(cinch).

앱 내부의 각 탭들이 각 코디네이터에 의해 효과적으로 관리되는 것을 볼 수 있다. 각 탭마다 하나씩의 코디네이터를 가진다.

아래는 tab bar controller를 관리하는 몇가지 방법이다.

MainTabBarController를 만든다

UITabBarController를 상속하는 MainTabBarController를 만든다.

이 컨트롤러는 각 탭에 대한 코디네이터를 프로퍼티로 갖는다.

• 하나의 코디네이터를 프로퍼티로 넣어보자.
• viewDidLoad()에서 각 코디네이터의 start()를 호출한다
  • 각 코디네이터가 기본 뷰컨트롤러를 준비하도록 한다
• viewControllers 프로퍼티를 탭바컨트롤러 배열로 지정한다.
  • 코디네이터에서 사용하는 각 내비게이션 컨트롤러를 이용한다

// MainTabBarController에 추가
let mainCoordinator = MainCoordinator(navigationController: UINavigationController())

override func viewDidLoad() {
    main.start()
    viewControllers = [main.navigationController]
}

각 뷰컨트롤러에 tab bar item 추가

추가하지 않으면 탭바에서 볼 수가 없다.

coordinator에서 start()할 때 설정해줄 수 있다.

// MainCoordinator
vc.tabBarItem = UITabBarItem(tabBarSystemItem: .favorites, tag: 0)

AppDelegate에서 rootViewController로 MainTabBarController를 지정한다

//AppDelegate
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
    // Override point for customization after application launch.
    window = UIWindow(frame: UIScreen.main.bounds)
    window?.rootViewController = MainTabBarController()
    window?.makeKeyAndVisible()

    return true
}

탭바컨트롤러를 처리하는 똑똑한 방법은 탭 하나마다 하나의 코디네이터를 두는 것이다.

이는 앱의 다른 부분들이 적절히 분리되도록 해준다.

5. segue를 어떻게 처리하는가?

segue는 뷰 컨트롤러 사이에 연결을 생성함으로서 스토리보드에 추가된다.

segue는 iOS에 의해 자동으로, 또는 prepare(for segue:) 메서드를 호출함으로서 발동된다.

문제는 segue가 코디네이터의 주요 장점 중 하나를 헛되게 한다는 것이다: segue는 강제로 지정된 앱의 흐름을 만든다. 이는 뷰컨트롤러를 자유롭게 재배치하는 것을 막는다.

결론 : 가능하면 segue사용을 지양한다(적어도 글쓴이는 쓰지 않는다고 함).

6. 어떻게 프로토콜이나 클로저를 (코디네이터) 대신 사용하는가?

(코디네이터 타입 대신 프로토콜이나 클로저 사용하기)

코디네이터를 사용할 때 혼란스러울 수 있는 부분은 코디네이터와 delegate의 차이점이다. 사실은 코디네이터와 delegate는 다르지 않다 - 코디네이터는 그저 효과적으로 전문화된 delegate이다. 사실, 뷰컨트롤러를 관리하는 coordinator 하나의 이름을 delegate로 바꾸면 그대로 작동한다.

coordinator라는 이름을 쓰는 것의 장점은, 그것이 앱 전반의 내비게이션을 처리하는 전문화된 delegate임을 의미함이 명확하다는 것이다. 당신은 하나의 뷰컨트롤러에 몇몇의 서로 다른 delegate를 가질 수 있고, 앱 내부에서 함께 작동하겠지만, 당신이 그 이름을 그저 delegate로 짓는다면 혼란이 올 수 있다. 이것을 coordinator라고 이름지음으로써 우리는 역할을 명확하게 만들 수 있다: 이것이 앱을 발전시키는 요소이다.

코디네이터의 이름을 delegate로 변경하는 대신 두가지 대안이 있다.

• 프로토콜 사용하기
• 클로저 사용하기

프로토콜 사용하기

• 큰 앱일 때 좋은 방법이다.
• 구체적인 구현을 자유롭게 다르게 사용할 수 있기 때문

먼저 메인 코디네이터 내의 VC 생성 메서드를 보고 공통 프로토콜을 만든다.

여기서는 buySubscription() 과 createAccount() 가 존재하므로, 이것들을 새 프로토콜로 묶을 수 있다.

// Buying
protocol Buying: AnyObject {
    func buySubscription()
}

// AccountCreating
protocol AccountCreating: AnyObject {
    func createAccount()
}

코디네이터가 위의 프로토콜을 채택하도록 한다

// MainCoordinator
class MainCoordinator: Coordinator, Buying, AccountCreating

ViewController가 구체 타입 대신 프로토콜을 참조하도록 한다

// ViewController
weak var coordinator: (Buying & AccountCreating)?

이제 두 프로토콜이 구현되는 한, 어떻게 구현하는지는 신경 쓸 필요가 없다 - 그것은 코디네이터일수도 있고, 아닐 수도 있다.

프로토콜을 사용하면…

프로토콜을 사용하는 것은 큰 앱을 작업하면서 더 많은 유연성을 필요로 할 때 매우 유용하다.

• 원할 때 자유롭게 새로운 프로토콜을 추가할 수 있다
• A/B 테스트를 위해 다른 코디네이터로 전환하기 쉽다
• 훨씬 더 유연하다 - 프로토콜은 우리가 원하는 특정 타입이 아닌 원하는 동작을 기술하는 것이기 때문

클로저 사용하기

코디네이터 구체타입과 프로토콜을 모두 사용하지 않고, 대신 클로저를 사용하는 방법도 있다.

뷰컨트롤러에 의해 발동되는 액션이 1~2개뿐일 때 유용하다.

ViewController의 메서드를 프로퍼티로 정의한다

// ViewController
var buyAction: (() -> Void)?
var createAccountAction: (() -> Void)?

사용할 때는 아래와 같이 호출한다

// ViewController
@IBAction func buyTapped(_ sender: Any) {
    buyAction?()
}

@IBAction func createAccountTapped(_ sender: Any) {
    createAccountAction?()
}

코디네이터에서 해당 클로저들을 정의해 준다

코디네이터가 뷰컨을 생성할 때 해당 클로저들을 어떻게 사용할지 정의해 준다.

• 기존 coordinator 프로퍼티를 삭제하고
• buyAction과 createAccountAction 프로퍼티를 설정한다

// MainCoordinator
vc.buyAction = { [weak self] in
    self?.buySubscription()
}

vc.createAccountAction = { [weak self] in
    self?.createAccount()
}

이렇게 만들면 뷰컨트롤러는 코디네이터가 내비게이션을 제어한다는 것도 모르게 할 수 있다.

클로저를 사용하면..

• 코디네이터에게 단지 1개 또는 2개의 콜백만을 보낼 때 좋다
• 뷰컨트롤러를 완전히 독립적으로 만들 수 있다 - 코디네이터의 존재조차 모르게
• 하지만 규모를 키우기에는 좋지 않다 - 3개 이상의 클로저 프로퍼티를 추가하다 보면 프로토콜로 바꾸고 싶어질 것.

https://khanlou.com/tag/advanced-coordinators/
코디네이터 패턴을 만든 Khanlou의 블로그 글을 읽어보기를 추천.