[Coordinator] Coordinators Redux

오늘은 보다 더 구현과 가까운 Coordinator 관련 블로그 글을 읽어 보고자 합니다 💪

원본 링크는 요기..

Three Problems

Overstuffed App Delegates

App Delegate에서 생길 수 있는 문제점은 여기에 모든 것을 쑤셔넣을 수 있다는 것이다 ,.. 예를 들어 앱의 root로 TabBarController를 사용하려면 그 tabBar의 child viewController를 세팅해줘야되는데 그 위치가 App Delegate가 될 확률이 높다는 것이징. 하지만 거기가 맞는 위치는 아니라는거…. 이러한 app configuration logic을 위해 조금 더 좋은 자리가 필요하다 !! (요 자리가 아마 coordinator가 되지 않을까 !)

Too Many Responsibilities

app delegate가 그랬던것처럼 각각의 view controller들도 너무 많은 역할들로 인해 고통받을 수 있습니다 … View Controller의 역할이 무엇인지도 확실하게 정하고 가야합니다 ..

 

우리가 view controller들에게 요구하는 역할들 …

1. Model-View Binding
2. Subview Allocation
3. Data Fetching
4. Layout
5. Data Transformation
6. Navigation Flow
7. User Input
8. Model Mutation
9. and many more besides

너무 많죠?

 

근데 이 중에서 어떤 부분들이 view controller에 남아야하는가 ... 그건 진짜 정하기 어렵다...

확실하게 데이터, 그래픽이 아닌 모든 것들이 controller 내부에 들어가다보니 controller가 결국 블랙홀처럼 모든 코드를 빨아들여서 massive view controller가 두둥...

이렇게 되지 않기 위해서 우리는 많은 주의를 기울여야한다 ..

Smooth Flow

Navigation Flow에 대해서도 얘기해보고 싶은데요 …

override func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
    let object = self.dataSource.object(at: indexPath)
    let detailViewController = SKDetailViewController(detailObject: object)
    self.navigationController?.pushViewController(detailViewController, animated: true)
}

흔하게 봤던 이 코드….이건 유감스럽게도 쓰레기입니다. 왜 그런지 한줄씩 살펴봅시다.

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

let object = self.dataSource.object(at: indexPath)

첫번째 줄은 문제 없습니다 ㅋ

let detailViewController = SKDetailViewController(detailObject: object)

여기서부터 약간 문제가 생기기 시작하는데요…. 새로운 view controller를 생성하고 configure하고 있죠?

그러면서 다음에 어떤 객체가 오게 되는지, 어떻게 configure하는지.. 너무 많은 것들에 대해 알게 되버립니다.

self.navigationController?.pushViewController(detailViewController, animated: true)

여기서부터 완전…모든게 길을 벗어나기 시작합니다. viewController가 부모까지 붙잡기 시작…그리고 부모한테 할 일에 대해서 직접 메세지를 보내고 있습니다. bossing their parent around라는 표현을 사용했는데 child는 절대 parent를 boss around 해서는 안되지 ! children은 그들의 부모가 누군지도 알아서는 안된다~~

Coordinators

What is a coordinator?

coordinator란 하나 이상의 view controller들에게 명령을 내리는 객체다.

Flow logic을 view controller부터 분리하고 상단의 레이어로 하나 더 생성함으로써 더 효율적인 코드를 작성할 수 있게 되는 것.

 

일단 App Coordinator가 있는데 최상단의 coordinator같은 느낌인거징.

view controller들을 생성하고 configure하거나 새로운 child coordinator를 생성할 수도 있고~ (위에서 말했던 overstuffed app delegate의 문제를 app coordinator를 통해 해결할 수 있음!)

 

그럼 Coordinator의 역할은 무엇이 돼야하나?

나는 네비게이션만 생각했는데 이 저자는 model mutation까지 얘기하고 있네… (user’s change를 db에 저장하거나 API에 PUT, POST 요청을 보내는 등… 유저의 데이터를 변형할 수 있는 행위들까지 coordinator가 담당해야한다….) 왜 그래야하는지 좀 궁금하당…ㅇ ㅡㅇ 그냥 딱 navigation만 담당하는게 낫지않나…아닌가….

 

이 밑에 왜 Model mutation까지 담당해야하는지 알려주는거가튼데 coordinator를 적용하고 나면 view controller는 presented, fetch data, transform it for presentation, display it 까지 담당하고 변형은 할 수 없다 ! alter하는건 coordinator의 역할…? 아직 잘 이해가 안됩니다 ㅜㅜ 예시를 일단 봐야겠군….

Code Example

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
    window = UIWindow(frame: UIScreen.main.bounds)
    rootViewController = UINavigationController()

    appCoordinator = SKAppCoordinator(navigationController: rootViewController)
    appCoordinator?.start()

    window?.makeKeyAndVisible()
    return true
}

App delegate에서는 app의 window, root view controller를 세팅하고 app coordinator를 fire up!한다. 이때 appCoordinator의 initialization과 start 메서드는 분리돼있다는 것을 확인~ 이를 통해 생성하는 건 맘대로 하고 원할 때 start하면 된다는 것을 알 수 있당.

 

그리고 이때 중요한건 Coordinator는 plain NSObject라는 것 ! 

closed source라서 내부 동작을 다 열어볼 수 없는 UIViewController와 같은 개념과는 다르게 Coordinator는 우리가 직접 만든 단순한 객체이고 이러한 객체가 앱의 flow를 담당하게 되면 모든걸 단순하게 만든다 !

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

func start() {
    if isLoggedIn() {
        showContent()
    } else {
        showAuthentication()
	}
}

이 start 메서드는 appCoordinator 내부의 start 메서드

이전에는 이러한 로직을 viewController 혹은 appDelegate에 넣었을텐데…좋지 않음! 약간 이 부분을 보니까 RIBs에서 ViewlessRIB을 보는 듯한 느낌 ?

func showAuthentication() {
    let authCoordinator = SKAuthenticationCoordinator(navigationViewController: self.navigationController)
    authCoordinator.delegate = self
    authCoordinator.start()
    self.childCoordinators.append(authCoordinator)
}

이 메서드 안에서 child Coordinator를 생성하고 App Coordinator의 childCoordinators 배열에 추가함으로써 메모리에서 해제되는 것을 방지하고 있음! 그치… 원래는 메서드 내부에서 생성된 객체는 메서드가 끝나면 메모리에서 해제되니까…ㅇ ㅡㅇ

 

child coordinator는 view controller들을 생성하고 걔네한테 일을 시킴. 그리고 그게 끝나면 메세지를 줌 ! 그리고 일이 끝나면 자기 자신을 clean up 하고 parent한테 메세지를 주기 위해서 delegate를 사용함.

func coordinatorDidAuthenticate(_ coordinator: SKAuthenticationCoordinator) {
    if let index = self.childCoordinators.firstIndex(where: { $0 === coordinator }) {
        self.childCoordinators.remove(at: index)
    }
    showContent()
}

Authentication이 끝나면 delegate로 호출을 받을거구 child coordinator로 하여금 메모리에서 해제되도록 허용해줌ㅇㅇ

AuthCoordinator 내부에서는 필요한 view controller들을 생성하고 받은 navigation controller로 Push!

class AuthCoordinator {

    var navigationController: UINavigationController

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

}

func start() {
		// sign up, log in 버튼이 있는 viewController
    let firstRunViewController = SKFirstRunViewController()
    firstRunViewController.delegate = self
    navigationController.pushViewController(firstRunViewController, animated: false)
}

FirstRunViewController 안에는 signup 버튼이 있고 이거에 대한 delegate를 AuthCoordinator에서 갖고 있음

func firstRunViewControllerDidTapSignup(_ firstRunViewController: SKFirstRunViewController) {
    let signUpViewController = SKSignUpViewController()
    signUpViewController.delegate = self
    navigationController?.pushViewController(signUpViewController, animated: true)
}

여기서도 마찬가지로 signUpViewController의 delegate를 채택하면서 signUpViewController에서 발생하는 이벤트에 대한 처리를 해줄 수 있게됨

// 여기서 signup API request 실행하고 authentication token 저장하고 parent coordinator에게 다 끝났어~~~ 알려주게되는고지
func signUpViewController(_ signUpViewController: SKSignUpViewController, didTapSignupWithEmail email: String, password: String) {
    //...
}

결국 user input같은 이벤트가 view controller에서 일어나면 view controller는 그 이벤트를 delegate로 coordinator에게 전달하고 실제 일 처리는 coordinator가 하는고지… 흠 그럼 view model의 역할까지 coordinator가 하는건가? MVVM-C는 그럼 기존 coordinator의 역할인 navigation + model mutation을 viewModel과 coordinator가 각각 model mutation, navigation을 맡게 분리하는건가? 알아봐야겠군….

Why are coordinators great?

1. viewController들의 역할이 분리됨
   이제 ViewController는 데이터를 보여주는 방법 외에는 아무것도 모름 ! 이벤트가 발생하면 delegate를 호출하는 것 외에는 아무것도 하지않음…ㅇㅅㅇ
2. ViewController가 재사용가능해짐
3. 앱의 모든 작업과 하위 작업은 이제 캡슐화되는 전용 방법이 있다.
4. 코디네이터는 side effect과 디스플레이 바인딩을 분리한다.
5. 코디네이터는 당신이 완전히 통제할 수 있는 대상이다.
   예를 들어 UIKit이라는 프레임워크를 사용할 때는 viewDidLoad 메서드가 불릴때까지 기다리는 등 프레임워크에 의존하여 개발해야하는 부분이 있었지만 plain NSObject인 coordinator를 사용하면 내가 모든 flow를 통제할 수 있다는 장점이 있다는 점 !!

---

어느정도 코드를 통해 감을 잡았으니 다음에는 코데코 튜토리얼을 실습해보는 글로 돌아오겠습니다 ! 🫡