错误检查：CloudKit MacCatalyst didReceiveRemoteNotification

Question

我正在使用 MacCatalyst 将 iOS/iPadOS 应用程序移植到 MacOS。该应用程序以所有方式使用 CloudKit 和函数，除了一个：当从另一台设备提交 CloudKit 更新时，不会在 MacOS 版本上调用UIApplicationDelegate方法 。didReceiveRemoteNotification

在应用程序中起作用的事情：

• CKDatabaseOperation向 CloudKit提交包括更新和订阅在内的 s
• 从 CloudKit 手动检索数据库更新
• UIApplicationDelegate方法在调用时didRegisterForRemoteNotificationsWithDeviceToken触发并UIApplication.isRegisteredForRemoteNotifications返回 trueUIApplication.registerForRemoteNotifications
• 设置CKSubscription.NotificationInfo调用在 MacOS 中正确显示的警报通知
• UNUserNotificationCenterDelegate方法，willPresent当调用警报通知并且应用程序在前台时
• didReceiveRemoteNotification 在 iOS 和 iPad（物理设备）上

有没有人在使用 MacCatalyst 时调用过UIApplicationDelegate方法didReceiveRemoteNotification？

更新：应用程序最终didReceiveRemoteNotification在发送更新 30 分钟后触发该方法，但在其他更新中，该方法即使在数小时后也不会触发。有任何想法吗？

Answer 1

我有一个可能的解决方案，尽管我看到的问题与您描述的略有不同。这是快速版本：至少使用.userInitiated qualityOfServiceCatalyst。

\n

这就是我认为正在发生的事情。

\n

CKOperation.h 提供了此文档：

\n

@discussion CKOperations behave differently depending on how you set qualityOfService.\n *\n *  @code\n *  Quality of Service | timeoutIntervalForResource | Network Error Behavior | Discretionary Behavior\n *  -------------------+----------------------------+------------------------+-----------------------\n *  UserInteractive    | -1 (no enforcement)        | fail                   | nonDiscretionary\n *  UserInitiated      | -1 (no enforcement)        | fail                   | nonDiscretionary\n *  Default            | 1 week                     | fail                   | discretionary when app backgrounded\n *  Utility            | 1 week                     | internally retried     | discretionary when app backgrounded\n *  Background         | 1 week                     | internally retried     | discretionary\n *  @endcode\n * timeoutIntervalForResource\n * - the timeout interval for any network resources retrieved by this operation\n * - this can be overridden via CKOperationConfiguration\'s timeoutIntervalForResource property\n *\n * Network Error Behavior\n * - when a network request in service of a CKOperation fails due to a networking error, the operation may fail with that error, or internally retry the network request.  Only a subset of networking errors are retried, and limiting factors such as timeoutIntervalForResource are still applicable.\n *\n * Discretionary Behavior\n * - network requests in service of a CKOperation may be marked as discretionary\n * - discretionary network requests are scheduled at the description of the system for optimal performance\n *\n * CKOperations have a default qualityOfService of Default.\n

\n

请注意，默认的自由裁量行为是“应用程序后台运行时的自由裁量”，并且自由裁量行为的描述表示“自由裁量网络请求在系统的[自由裁量]上进行调度，以获得最佳性能”。我认为这就是 Catalyst 中正在发生的事情；如果应用程序不在前台，则请求将变为任意的\xe2\x80\x94，即可推迟。而且，就我而言，延期似乎是无限期的。

\n

这就是我所看到的。

\n

\n
• 我在 iPhone 上启动了该应用程序
\n
• 我在 Mac 上启动了该应用程序
\n
• 我将 Mac 应用程序置于“后台”（即，它不再处于活动状态）
\n
• 我在 iPhone 上进行了更改
\n
• Mac 收到远程通知
\n
• 为了响应远程通知，Mac 尝试下载（获取）记录
\n
• 下载请求从未完成
\n

\n

这就是我所做的。

\n

我已经CKOperationGroup为我的所有CKOperations 分配了一个值，并且我已经为 分配了一个值defaultConfiguration.qualityOfService。qualityOfService在 Catalyst 上，我更改了一些内容，以便我分配的最小值为.userInitiated。这使得问题在测试中消失了。（需要明确的是，我尝试了很多方法；这是唯一有效的方法。）昨晚我将一个版本投入生产，并且 \xe2\x80\x94 到目前为止至少 \xe2\x80\x94 我不再看到问题也在那里。

\n

如果你不用s，不用担心，直接在s上CKOperationGroup设置即可；这应该同样有效，只是不完全是我所做的。qualityOfServiceCKOperation

\n

我通过反馈向 Apple 提交了错误。

\n