GNSS_GEOFENCE_STATE列舉單一地理柵欄的各種狀態。
語法
typedef enum {
GNSS_GeofenceState_Unknown,
GNSS_GeofenceState_Entered,
GNSS_GeofenceState_Exited
} GNSS_GEOFENCE_STATE;
常數
GNSS_GeofenceState_Unknown 地理柵欄的狀態未知。 |
GNSS_GeofenceState_Entered 地理柵欄已輸入。 |
GNSS_GeofenceState_Exited 地理柵欄已結束。 |
言論
HLOS 會使用下列位掩碼來要求地理柵欄的狀態變更警示:
#define GNSS_GEOFENCEALERTTYPE_ENTRY GNSS_GeofenceState_Entered // Enter Geofence
#define GNSS_GEOFENCEALERTTYPE_EXIT GNSS_GeofenceState_Exited // Exit Geofence
當地理柵欄的先前狀態未知或已結束,且裝置現在已進入地理柵欄時,就會引發進入警示。
進入地理柵欄之前的狀態,且裝置現在已結束地理柵欄時,就會引發結束警示。 如果先前的地理柵欄狀態未知,且裝置目前不在地理柵欄之外,則不會產生任何結束警示。
當柵欄先前的已知狀態位於柵欄內時,位置平臺只會將結束觸發程式傳送至應用程式。 這是避免地理柵欄設定上結束事件的閒聊設計決策(例如,當使用者未預期使用者設定出家柵欄時,如果設定通知時已不在家外,則必須收到通知。 不過,位置平臺可以處理 GNSS 驅動程式傳送結束事件的位置,但不建議使用,因為 GNSS 配接器與 GNSS 驅動程式之間的互動將會變得非常詳細。 由於使用者輸入地理柵欄的機會遠小於地理柵欄外部的使用者,此行為可減少 GNSS 驅動程式與 GNSS 配接器之間的必要互動。 例如,在推送至 GNSS 驅動程式的 100 個地理柵欄的情況下,且使用者全都不在其中,而不需要此行為,就必須傳送至 GNSS 適配卡 100 結束通知。 專案事件發生類似這種情況的可能性很小。
地理柵欄狀態轉換和相關聯的警示如下所示。 為了簡單起見,隱含的遲滯和地理柵欄界限條件。
此狀態圖表的主要層面包括:
從GNSS_GeofenceState_Unknown轉換為GNSS_GeofenceState_Exited狀態時,不會引發警示。
當 GNSS 引擎完全無法追蹤任何地理柵欄時,必須引發單一全域追蹤狀態警示,而不是每個地理柵欄的一個警示。 GNSS 引擎可以維護每個柵欄的最後一個已知狀態,而不是轉換至GNSS_GeofenceState_Unknown狀態,因此當它能夠再次追蹤時,可以根據新的進入/退出偵測來引發所需的地理柵欄警示。
不過,目前不需要維護此最後一個已知狀態,因為一旦 GNSS 驅動程式引發事件,gnss_geofences_tracking_status為 FAILURE,HLOS 中的位置平臺就會開始執行地理柵欄追蹤。 在此期間,如果可以再次追蹤地理柵欄,GNSS 引擎應繼續以電源優化的方式檢查。 IHV 可以使用優化,以低功率進行此偵測。 優化常見的技術包括下列各項:
漸進式退場
等候指出裝置移動的低成本訊號,例如加速器數據或行動數據/WiFi 變更通知。
使用公用地理位置 WinRT API 從 HLOS 要求低精確度距離追蹤會話。
衛星訊號的低功率檢查。
當 GNSS 引擎能夠再次追蹤地理柵欄時,它會將gnss_geofence_tracking_status設定為 GNSS 配接器/HLOS,藉此進行通訊
GNSS 配接器會發出GNSS_ResetGeofenceTracking命令,並使用每個地理柵欄目前的進入/結束準則重新新增目前作用中的地理柵欄。 如果要追蹤的地理柵欄集已變更,或在狀態中追蹤任何地理柵欄已變更,則需要這麼做。
要求
要求 | 價值 |
---|---|
標頭 | gnssdriver.h |