CLLocationManager и iBeacons: необходим ли requestState (для: региона)?

Question

Я пытаюсь создать приложение iBeacons с Swift 4 в iOS 10. Многие источники рекомендуют следующее:

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

для обработки случая, когда приложение запускается внутри области маяка.Однако этот подход, кажется, вызывает побочные эффекты и ошибки синхронизации в некоторых ситуациях.

Теперь я нашел эту статью StackOverflow Понимание iBeacons в 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, а затем хочет визуально показать пользователю состояние региона.Удобно иметь возможность вызывать requestState при загрузке представления, а затем обновлять отображение при выполнении обратного вызова.

Определенные побочные эффекты и проблемы, вызванные дополнительными обратными вызовами, действительно зависят от того, что выположить внутри обратного вызова. Если вы запускаете или прекращаете мониторинг в этих обратных вызовах, очень легко создать петли обратной связи, которые вызывают проблемы.