ios - 使用 WCSession 的具有自定义意图的 Siri 快捷方式

Question

我们的应用程序还包含一个 Watch Extension。该应用程序的部分功能是在任一设备上启动或停止进程，并通过发送事件及其发生日期来通知对方。我们现在还想为此使用具有自定义意图的 Siri 快捷方式。目前我们没有运行 watchOS 5 的 watch ，因此我们只能在模拟器中进行测试。

关注苹果 SoupChef示例应用程序，我们设法让快捷方式在两个设备上运行，根据需要在后台执行任务。但是，激活 WCSession 以将消息发送到其他设备失败并出现错误

[WC] -[WCXPCManager onqueue_reconnect]_block_invoke error reconnecting to daemon due to NSXPCConnectionInterrupted

被反复调用。

在尝试将消息发送到 IntentHandler 中的其他设备之前

func handle(intent: OurIntent, completion: @escaping (OurIntentResponse) -> Void)

我们正在尝试在其开始时激活 session

func confirm(intent: OurIntent, completion: @escaping (OurIntentResponse) -> Void) {
    let _ = Communicator.sharedInstance

    // ...
}

Communicator 是作为单例实现的，尝试在它的 intit 方法中激活 session ，如下所示:

if WCSession.isSupported() {
  let session = WCSession.default
  session.delegate = self
  session.activate() // fails with error mentioned above
}

我们知道 Apple documentation 中提到的应用程序扩展中可用 API 的限制。但这里似乎不是这种情况，因为我们通过了 WCSession.isSupported()。

不在后台运行快捷方式，而是让它们打开应用程序当然可以解决问题，但这会使快捷方式在我们的情况下变得毫无用处。

有谁知道我们是否错过了在这里使用 WCSession 的任何先决条件，或者根本不可能吗？如前所述，我们目前只能在模拟器中进行测试。这可能是问题所在吗？

非常感谢任何帮助

Answer 1

由于优先级发生了变化，我们最近才继续使用 Siri 快捷方式。因为我们没有找到问题的解决方案，而是我们的自定义 IntentResponses 也遇到了问题，所以我们决定在我们的应用程序/watchExtension 中处理所有逻辑。所以现在在我们的 IntentHandler 的 handle 方法中，我们只需将 .continueInApp 传递给完成 block 。然后，这会将应用带到前台，在前台调用现在实现的可选委托(delegate)方法。

func application(_ application: UIApplication,
             continue userActivity: NSUserActivity,
             restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void) -> Bool {

    if let intent = userActivity.interaction?.intent {
    // make desired viewController frontmost
    // ...

        if intent is OurStartIntent {
            // check state and send message to watch
        }

        else if intent is OurStopIntent {
            // check state and send message to watch
        }
    }
// ...

watch ExtensionDelegate 的等效方法是

func handle(_ userActivity: NSUserActivity)

识别意图我们首先检查应用程序是否处于处理意图的状态，例如使用 StartIntent 时进程尚未运行。这以前是我们为 IntentHandler 的确认方法设计的任务，我们为这些情况实现了自定义 IntentResponses。然而，这只有在用户点击建议的快捷方式时才有效，并收到无法处理此意图的解释。对于语音快捷方式，我们的 IntentResponses 被忽略了。 Siris 的回答总是:“抱歉，应用程序出现问题”。另一个虽然在我们的例子中是个小问题，但由于某种原因，上面提到的 watch ExtensionDelegate 方法总是被调用两次。还描述了here通过传递时间戳以及可能的解决方案。

我希望这可能对某人有所帮助。

托斯滕