我们的应用程序还包含一个手表扩展程序。应用程序功能的一部分是在任一设备上启动或停止进程,并通过发送事件及其发生日期来通知其对应方。现在,我们还想为此使用Siri快捷方式和自定义意图。 目前,我们没有运行watchOS 5的手表,因此我们只能在模拟器中对其进行测试。
在苹果公司SoupChef示例应用程序的帮助下,我们设法使快捷方式都在两台设备上运行,并根据需要在后台执行其任务。但是,激活WCSession以便将消息发送到另一台设备失败,并显示错误
由于NSXPCConnectionInterrupted,[WC]-[WCXPCManager onqueue_reconnect] _block_invoke错误重新连接到守护程序
被反复呼叫。
在尝试将消息发送到IntentHandler的其他设备之前
func handle(intent: OurIntent, completion: @escaping (OurIntentResponse) -> Void)
我们正在尝试从会话的最开始激活会话
func confirm(intent: OurIntent, completion: @escaping (OurIntentResponse) -> Void) {
let _ = Communicator.sharedInstance
// ...
}
Communicator被实现为一个单例,试图通过intit方法激活会话,如下所示:
if WCSession.isSupported() {
let session = WCSession.default
session.delegate = self
session.activate() // fails with error mentioned above
}
我们知道苹果documentation中提到的有关App Extensions中可用API的局限性,但是这里似乎不是这样,因为我们通过了WCSession.isSupported()。
不在后台运行快捷方式,而是让它们打开应用程序当然可以解决问题,但这在我们的情况下会使快捷方式变得毫无用处。
有人知道我们是否错过了使用WCSession的任何先决条件,或者根本不可能吗?如前所述,我们目前只能在模拟器中进行测试。这可能是问题吗?
非常感谢您的帮助
答案 0 :(得分:0)
由于优先级的改变,我们直到最近才继续使用Siri快捷方式。因为我们没有找到解决问题的方法,但是自定义IntentResponses遇到了问题,所以我们决定处理app / watchExtension中的所有逻辑。 因此,现在在IntentHandler的handle方法中,我们只需将.continueInApp传递给完成块。然后,这会将应用程序带到调用现在实现的可选委托方法的前台。
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
}
}
// ...
手表ExtensionDelegate的等效方法是
func handle(_ userActivity: NSUserActivity)
确定意图后,我们首先检查应用程序是否处于处理意图的状态,例如使用StartIntent时该进程尚未运行。这以前是我们打算用于IntentHandler的Confirm方法的任务,并且我们为这些情况实现了自定义IntentResponses。但是,只有在用户点击建议的快捷方式时,这才能很好地工作,并收到无法处理此意图的解释。对于语音快捷方式,我们的IntentResponses被忽略。 Siris的回答总是:“对不起,该应用程序有问题”。 尽管在我们的案例中还有一个小问题,但由于某种原因,上面提到的watch ExtensionDelegate方法总是被调用两次。还介绍了here以及通过传递时间戳的可能解决方案。
我希望这可以对某人有所帮助。
战栗