我应该从哪里呈现一个干净架构中的 MFMailComposeViewController？答案

【问题标题】：From where should I present an MFMailComposeViewController in a Clean Architecture?我应该从哪里呈现一个干净架构中的 MFMailComposeViewController？
【发布时间】：2017-07-27 08:16:43
【问题描述】：

您能否就MFMailComposeViewController 的放置位置提供一些建议？

在一个非 RxSwift 和非 Clean Architecture 项目中，我会在一些视图控制器中实现它，如下所示：

extension ViewController: MFMailComposeViewControllerDelegate {

    func presentMailComposer() {

        if !MFMailComposeViewController.canSendMail() {
            // TODO: - Handle error here
            return
        }

        DispatchQueue.global(qos: DispatchQoS.QoSClass.userInitiated).async {

            let mailComposeViewController = MFMailComposeViewController()
            mailComposeViewController.mailComposeDelegate = self
            mailComposeViewController.setToRecipients(["mail@example.com"])
            mailComposeViewController.setMessageBody("Message body", isHTML: false)

            DispatchQueue.main.async(execute: {
                self.present(mailComposeViewController, animated: true, completion: nil)
            })

        }

    }

    func mailComposeController(_ controller: MFMailComposeViewController, didFinishWith result: MFMailComposeResult, error: Error?) {
        if result == MFMailComposeResult.failed {
            // TODO: - Handle error here
        }
    }

}

在 Clean Architecture 中，您会将 Mail Composer 放在哪里？

您会从导航器/路由器中展示这个吗？它毕竟是一个“场景”，即使我们不一定有一个 Navigator/Router 和一个专用于 MailComposer 的 ViewModel。

有两个不同的地方可能会发生错误，我真的不认为导航器应该处理这些。

谢谢！

【问题讨论】：

标签： swift mfmailcomposeviewcontroller rx-swift clean-architecture

【解决方案1】：

Clean Architecture 背后的基本前提是“业务规则”，即应用程序的逻辑，不依赖于 UI 或由 UI 执行。相反，您的应用程序的逻辑处于控制之中。

这意味着应用程序的某些部分逻辑知道何时用户可以发送电子邮件，但它不知道具体如何发生。

如果您使用 RxSwift，您可以将用户交互视为模型转换。所以你的例子会变成：

func sendMail(recipients: [String], tile: String, message: String, isHTML: Bool) -> Observable<Bool>

上述内容可以作为闭包传递给您的逻辑，也可以嵌入到您的逻辑使用的协议中。

如果您想使用 Robert Martin 的特定结构，那么情况会有些不同，因为您根本不会在模型对象中使用 Rx。（他建议您的 Interactors &al. 不要依赖外部库。）

在这种情况下，Interactor 会向 Presenter 发送消息以通过 Response Model 对象显示电子邮件视图控制器，而 Controller 会将成功/失败结果发送回 Interactor，或者更有可能发送给不同的 Interactor。

这是 Bob 叔叔所说的他如何构建事物的方式：https://camo.githubusercontent.com/c34f4ed0203238af6e43b44544b864dffac6bc08/687474703a2f2f692e696d6775722e636f6d2f576b42414154792e706e67 然而，在他公开展示的一个 iOS Swift 应用程序中，他没有使用这种结构。 https://github.com/unclebob/MACS_GOMOKU

在您发表评论后进行详细说明，签名确实有效，但它需要一些支持结构...

首先，一个很好但不是绝对必要的部分，我们使视图控制器呈现反应：

extension Reactive where Base: UIViewController {

    func present(_ viewControllerToPresent: UIViewController, animated: Bool) -> Observable<Void> {
        return Observable.create { observer in
            self.base.present(viewControllerToPresent, animated: animated, completion: {
                observer.onNext()
                observer.onCompleted()
            })
            return Disposables.create()
        }
    }
}

不仅一个视图控制器只能由另一个视图控制器呈现，而且它必须是系统中当前不呈现任何内容的一个视图控制器。我们可以通过从根开始并向上遍历表示堆栈来找到该视图控制器：

extension UIViewController {

    static func top() -> UIViewController? {
        var result = UIApplication.shared.delegate.flatMap { $0.window??.rootViewController }
        while let child = result?.presentedViewController {
            result = child
        }
        return result
    }
}

现在，我们不再让某些视图控制器符合MFMailComposeViewControllerDelegate 协议，而是创建一个专用的 Reactive 类。

class MailComposeViewControllerDelegate: NSObject, UINavigationControllerDelegate, MFMailComposeViewControllerDelegate {

    let subject = PublishSubject<MFMailComposeResult>()

    func mailComposeController(_ controller: MFMailComposeViewController, didFinishWith result: MFMailComposeResult, error: Error?) {
        if let error = error {
            subject.onError(error)
        }
        else {
            subject.onNext(result)
        }
    }
}

所有这些都准备好后，编写 sendMail 函数就很容易了：

func sendMail(recipients: [String], tile: String, message: String, isHTML: Bool) -> Observable<MFMailComposeResult> {
    let delegate = MailComposeViewControllerDelegate()
    let controller = MFMailComposeViewController()
    controller.delegate = delegate
    return UIViewController.top()!.rx.present(controller, animated: true)
        .flatMap { delegate.subject }
}

就像我说的，你应该不直接调用这个函数。相反，您应该将其注入将调用它的对象中，以便您可以模拟它以进行测试。

同样的模式适用于 UIImagePickerController 甚至 UIAlertController！

您可能会发现我写的这篇文章读起来很有趣。它使用 promises 而不是 Rx，但原理是一样的：https://medium.com/@danielt1263/encapsulating-the-user-in-a-function-ec5e5c02045f

【讨论】：

我不认为签名会起作用。我不明白怎么做。然而！ MFMailComposeViewController 的问题是它必须从现有的视图控制器启动。只有现有的视图控制器和我的路由器/交互器知道视图控制器。如果sendMail 函数被用作一个用例，在我的域中定义为一个接口/协议，我看不出我怎么能呈现它.. 到海滩了！当我回来时，我会再次选择你的答案。似乎很有希望。谢谢丹尼尔。
我在答案中添加了解释如何实现该功能。
谢谢@Daniel。与此同时，我正在尝试在 RxSwift 中添加对 MFMailComposeViewController 的支持。我把它留在这里以供参考。 github.com/ReactiveX/RxSwift/issues/1378

【解决方案2】：

这取决于您决定管理项目的方式。

最终，邮件撰写器元素是一个 UI 元素，因此应该在 UI 处理类中执行它 - 例如您的 VC、您所做的某种扩展等。

在我看来，你可以做的是将你的邮件编写器子类化，并在它完成时创建一个完成块响应，然后相应地处理 UI 中的错误，这样它将自行管理（由于它是全局控制器，为此使用通用 VM 是浪费代码）。

然后，当您展示邮件编写器时，您可以让用户添加完成和失败块/使用来自 Rx 的信号来返回结果。

【讨论】：