协调员基本教程。 第二部分

在本教程的第一部分中，我总体上讨论了协调器的方法，并展示了一些与实现有关的常见示例。 为了与本文保持一致，请阅读上一部分。

在这一部分中，我想介绍一些使用协调器的极端情况。

我想最有趣的部分是：

• AppDelegate配置
• 管理启动选项
• 深度链接和协调员推送通知处理

我将逐步说明解决方案并进行解释。

如何使用主应用程序协调器配置AppDelegate？

由于所有导航逻辑都移至AppCoordinator，因此AppDelegate变得非常简单。

因此，您需要做的是创建一个协调器，注入rootController并调用start（）。

我们希望通过展示一个教程，展示一个身份验证流程，向他们介绍新功能或仅显示主屏幕来向用户介绍我们的应用程序。 我们应该谨慎处理这种行为。

假设我们有3种不同的情况：

• 用户应查看入门教程（我们将显示入门屏幕）
• 用户应登录（我们显示登录屏幕）
• 用户已完成之前的两个步骤，仅看到主屏幕

为了轻松处理所有这些情况，我们创建了一个枚举作为协调者的助手。 该枚举应检查所有标志，并返回协调器应遵循的正确方案。 我将其命名为实体讲师，因为它指示协调员接下来要做什么。

怎么处理呢？ 正如您在上一部分中所记得的，我告诉您有关BaseCoordinator的信息 ，其中包含子协调器数组。 所有协调员都继承它。 这意味着我们可以循环所有孩子并执行动作。 为此，我们只需添加一种方法即可处理DeepLink逻辑本身，也可以循环处理子代以找到可以处理它的方法。 它将像一棵树。 我们可以创建特定的协议来实现此目标。

让我们更新协调器协议：

现在，我们将两个带有空主体的方法添加到BaseCoordinator中，以使其保持可选状态。 孩子们可以继承这些方法之一，也可以两种都继承。 在某些情况下，可以使用不带选项的start来运行默认行为，但是如果继续进行深层链接方案，则应添加有关演示案例的信息。 如何实现呢？ 更好的方法是在项目中添加一些实体，其中包含所有深层链接快捷方式，并创建可以使用start（）方法发送的对象。

你想念枚举吗？ 让我们添加一个新的！ 它将是DeepLinkOption：

好处是，协调器中所有的DeepLink方法都将像切换为枚举一样。 是的，与上一个示例中的Instructor相同，您是正确的。

我们可以根据需要添加一些其他的build方法（带有…）：

在此迭代之后，如果我们返回AppDelegate并对其进行一些更新，它将看起来像这样：

好了，看起来不错吗？🤔然后您将收到一个推送通知或深层链接，您只需构建您的DeepLink并通过AppCoordinator进行此操作即可。

结论

在我们尝试在代码中实现的每个新解决方案中，我们都面临着很多极端的情况，并且还面临着一些不太漂亮的解决方案。 它不应该像炒作那样驱动开发，我们只需要逐步改进所有棘手的部分即可。

如果您有任何疑问或新的特定问题，请随时给我写信。 并检查整个实现的Github回购。