ios - CLLocationManager 和 iBeacons : is requestState(for: region) necessary?

Question

我正在尝试在 iOS 10 中使用 Swift 4 构建 iBeacons 应用程序。许多来源推荐以下内容:

func locationManager(_ manager: CLLocationManager, didStartMonitoringFor region: CLRegion) {
manager.requestState(for: region)
}

处理应用程序在信标区域内启动时的情况。然而，这种方法在某些情况下似乎会产生副作用和计时错误。

现在，我找到了这篇 StackOverflow 文章 Understanding iBeacons in iOS其中指出，“didDetermineState 仅在您开始监视时自动调用”。

果然，如果我省略对 requestState(for:region) 的调用，而只调用 locationManager.startMonitoring(for:region) 一切都会完美运行!

谁能证实情况确实如此？如果我调用 startMonitoring 那么就不需要 requestState？

注意:在开始监控之前，我将 notifyEntryStateOnDisplay 设置为 true。我想知道这是否与此有关。

Answer 1

是否需要调用 locationManager.requestState(for: Region) 完全取决于您的用例。

回调locationManager(_ manager: CLLocationManager, didDetermineState state: CLRegionState, for Region: CLRegion)将在以下情况下自动调用:

1. 当您第一次开始监控时。
2. 适用于所有区域状态更改。这包括 .outside -> .inside、.inside -> .outside 以及与 .unknown 之间的转换
3. 每当显示屏亮起时(仅当您设置受监控的 BeaconRegion notifyEntryStateOnDisplay=true 时)

因此，如果这些情况对您来说足够了，那么您不需要请求额外的回调。这通常是正确的。

但是，在一些罕见的用例中，显式请求新的回调会很有帮助。也许您的应用程序呈现了一个新的 View Controller ，然后想要直观地向用户显示区域状态。当 View 加载时能够调用 requestState ，然后在回调时更新显示，这很方便。

特定的副作用和由额外回调引起的问题实际上取决于您在回调中放入的内容。如果您在这些回调中开始或停止监视，则很容易创建导致问题的反馈循环。