前文 探讨了 ReSwift,它是基于「单向数据流」的架构方案,来解决 Massive View Controller 灾难。

Soroush Khanlou 写过一篇《8 Patterns to Help You Destroy Massive View Controller》,就多方面来改善工程的维护性和可测试性。

今天要讨论的是其中之一,即在解决「数据流问题」之后,再对视图层的 Navigator 进行解耦,所谓的「Flow Coordinators」。

什么是 Coordinator

Coordinator 是 Soroush Khanlou 在一次演讲中提出的模式,启发自 Application Controller Pattern

先来看看传统的作法到底存在什么问题。

1
2
3
4
5
func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
let item = self.dataSource[indexPath.row]
let vc = DetailViewController(item.id)
self.navigationController.pushViewController(vc, animated: true, completion: nil)
}

再熟悉不过的场景:点击 ListViewController 中的 table 列表元素,之后跳转到具体的 DetailViewController

实现思路即在 UITableViewDelegate的代理方法中实现两个 view 之间的跳转。

传统的耦合问题

看似很和谐。

好,现在我们的业务发展了,需要适配 iPad,交互发生了变化,我们打算使用 popover 来显示 detail 信息。

于是,代码又变成了这个样子:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
let item = self.dataSource[indexPath.row]
let vc = DetailViewController(item.id)
if (! Device.isIPad()) {
self.navigationController.pushViewController(vc, animated: true, completion: nil)
} else {
var nc = UINavigationController(rootViewController: vc)
nc.modalPresentationStyle = UIModalPresentationStyle.Popover
var popover = nc.popoverPresentationController
popoverContent.preferredContentSize = CGSizeMake(500, 600)
popover.delegate = self
popover.sourceView = self.view
popover.sourceRect = CGRectMake(100, 100, 0, 0)
presentViewController(nc, animated: true, completion: nil)
}
}

很快我们感觉到不对劲,经过理性分析,发现以下问题:

  • view controller 之间高耦合
  • ListViewController 没有良好的复用性
  • 过多 if 控制流代码
  • 副作用导致难以测试

Coordinator 如何改进

显然,问题的关键在于「解耦」,看看所谓的 Coordinator 到底起到了什么作用。

先来看看 Coordinator 主要的职责:

  • 为每个 ViewController 配置一个 Coordinator 对象
  • Coordinator 负责创建配置 ViewController 以及处理视图间的跳转
  • 每个应用程序至少包含一个 Coordinator,可叫做 AppCoordinator 作为所有 Flow 的启动入口

了解了具体概念之后,我们用代码来实现一下吧。

不难看出,Coordinator 是一个简单的概念。因此,它并没有特别严格的实现标准,不同的人或 App 架构,在实现细节上也存在差别。

但主流的方式,最多是这两种:

  • 通过抽象一个 BaseViewController 来内置 Coordinator 对象
  • 通过 protocol 和 delegate 来建立 Coordinator 和 ViewController 之间的联系,前者对后者的「事件方法」进行实现

由于个人更倾向于低耦合的方案,所以接下来我们会采用第二种方案。

事实上 BaseViewController 在复杂的项目中,也未必是一种优秀的设计,不少文章采用 AOP 的思路进行过改良。

好了,首先我们定义一个 Coordinator 协议。

1
2
3
4
protocol Coordinator: class {
func start()
var childCoordinators: [Coordinator] { get set }
}

Coordinator 存储了「子 Coordinators」 的引用列表,防止它们被回收,实现相应的列表增减方法。

1
2
3
4
5
6
7
8
extension Coordinator {
func addChildCoordinator(childCoordinator: Coordinator) {
self.childCoordinators.append(childCoordinator)
}
func removeChildCoordinator(childCoordinator: Coordinator) {
self.childCoordinators = self.childCoordinators.filter { $0 !== childCoordinator }
}
}

我们说过,每个程序的 Flow 入口是由 AppCoordinator 对象来启动的,在 AppDelegate.swift 写入启动的代码.

1
2
3
4
5
6
7
8
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
self.window = UIWindow(frame: UIScreen.main.bounds)
self.window?.rootViewController = UINavigationController()
self.appCoordinator = AppCoordinator(with: window?.rootViewController as! UINavigationController)
self.appCoordinator.start()
return true
}

回到我们之前 ListViewController 的例子,我们重新梳理下,看看如何结合 Coordinator。假设需求如下:

  • 如果用户未登录状态,显示登录视图
  • 如果用户登录了,则显示主视图列表

定义 AppCoordinator 如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
final class AppCoordinator: Coordinator {
fileprivate let navigationController: UINavigationController
init(with navigationController: UINavigationController) {
self.navigationController = navigationController
}
override func start() {
if (isLogined) {
showList()
} else {
showLogin()
}
}
}

那么如何在 AppCoordinator 中创建和配置 view controller 呢?拿 LoginViewController 为例。

1
2
3
4
5
6
7
8
9
10
11
12
13
private func showLogin() {
let loginCoordinator = LoginCoordinator(navigationController: self.navigationController)
loginCoordinator.delegate = self
loginCoordinator.start()
self.childCoordinators.append(loginCoordinator)
}
extension AppCoordinator: LoginCoordinatorDelegate {
func didLogin(coordinator: AuthenticationCoordinator) {
self.removeCoordinator(coordinator: coordinator)
self.showList()
}
}

再来看看如何定义 LoginCoordinator

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
import UIKit
protocol LoginCoordinatorDelegate: class {
func didLogin(coordinator: LoginCoordinator)
}
final class LoginCoordinator: Coordinator {
weak var delegate:LoginCoordinatorDelegate?
let navigationController: UINavigationController
let loginViewController: LoginViewController
init(navigationController: UINavigationController) {
self.navigationController = navigationController
self.loginViewController = LoginViewController()
}
override func start() {
self.showLogin()
}
func showLogin() {
self.loginViewController.delegate = self
self.navigationController.show(self.loginViewController, sender: self)
}
}
extension LoginCoordinator: LoginViewControllerDelegate {
func didLogin() {
self.delegate?.didLogin(coordinator: self)
}
}

正如 UIKit 基于 delegate 的设计,我们靠这种方式真正实现了对 view controller 进行了解耦。

同理 LoginViewController 也存在相应的 LoginViewControllerDelegate 协议。

1
2
3
4
5
6
7
8
9
10
import UIKit
protocol LoginViewControllerDelegate: class {
func didLogin()
}
final class LoginViewController: UIViewController {
weak var delegate:LoginViewControllerDelegate?
……
}

这样,一套基本的 Coordinator 方案就出炉了。当然,目前还是非常基础的功能子集,我们完全可以在这个基础上扩展得更加强大。

适配多入口

显然,一个成熟的 App 会存在多样化的入口。除了我们一直在讨论的 App 内跳转之外,我们还会遇到以下的路由问题:

  • Deeplink
  • Push Notifications
  • Force Touch

常见的,我们很可能需要在手机上点击一个链接之后,直接链接到 app 内部的某个视图,而不是 app 正常打开时显示的主视图。

AndreyPanov 的方案解决了这个问题,我们需要对 Coordinator 再进行拓展。

1
2
3
4
5
protocol Coordinator: class {
func start()
func start(with option: DeepLinkOption?)
var childCoordinators: [Coordinator] { get set }
}

增加了一个 DeepLinkOption? 类型的参数。这个有什么用呢?

我们可以在 AppDelegate 中针对不同的程序唤起方式都用 Coordinator 进行启动。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
let notification = launchOptions?[.remoteNotification] as? [String: AnyObject]
let deepLink = buildDeepLink(with: notification)
self.applicationCoordinator.start(with: deepLink)
return true
}
func application(_ application: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable : Any]) {
let dict = userInfo as? [String: AnyObject]
let deepLink = buildDeepLink(with: dict)
self.applicationCoordinator.start(with: deepLink)
}
func application(_ application: UIApplication, continue userActivity: NSUserActivity, restorationHandler: @escaping ([Any]?) -> Void) -> Bool {
let deepLink = buildDeepLink(with: userActivity)
self.applicationCoordinator.start(with: deepLink)
return true
}

利用 buildDeepLink 方法对不同的入口方式判断输出相应的 flow 类型。

我们对之前的业务需求进行相应的扩展,假设存在以下三种不同的 flow 类型:

1
2
3
4
5
enum DeepLinkOption {
case login // 登录
case help // 帮助中心
case main // 主视图
}

我们来实现下 AppCoordinator 中的新 start 方法:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
override func start(with option: DeepLinkOption?) {
//通过 deeplink 启动
if let option = option {
switch option {
case .login: runLoginFlow()
case .help: runHelpFlow()
default: childCoordinators.forEach { coordinator in
coordinator.start(with: option)
}
}
//默认启动
} else {
……
}
}

总结

本文专门介绍了 Coordinator 模式来对 iOS 开发中的 navigator 进行了深度的解耦。然而当今仍没有权威标准的解决方案,感兴趣的同学建议去 github 参考下其他更优秀的实践方案。

接下来的第三篇文章计划就 Swift 语言的 extension 语法进行深入的介绍和分析,它是构建「类 Vue + Vuex」打法的核心之一。