enumeración GNSS_GEOFENCE_STATE (gnssdriver.h)

GNSS_GEOFENCE_STATE enumera los distintos estados de una sola geovalla.

Sintaxis

typedef enum {
  GNSS_GeofenceState_Unknown,
  GNSS_GeofenceState_Entered,
  GNSS_GeofenceState_Exited
} GNSS_GEOFENCE_STATE;

Constantes

GNSS_GeofenceState_Unknown El estado de la geovalla es desconocido.
GNSS_GeofenceState_Entered Se ha escrito la geovalla.
GNSS_GeofenceState_Exited Se ha salido de la geovalla.

Observaciones

Los HLOS usan las siguientes máscaras de bits para solicitar alertas de cambio de estado para geovallas:

#define GNSS_GEOFENCEALERTTYPE_ENTRY  GNSS_GeofenceState_Entered    // Enter Geofence
#define GNSS_GEOFENCEALERTTYPE_EXIT   GNSS_GeofenceState_Exited     // Exit Geofence

Se genera una alerta de entrada cuando el estado anterior de la geovalla se desconoce o sale y el dispositivo ha entrado ahora en la geovalla.

Se genera una alerta de salida cuando se especificó el estado anterior de la geovalla y el dispositivo ha salido de la geovalla. Si se desconoce el estado anterior de la geovalla y el dispositivo está actualmente fuera de la geovalla, no se generará ninguna alerta de salida.

La plataforma de ubicación solo envía un desencadenador de salida a las aplicaciones cuando el estado conocido anterior para una barrera está dentro de la barrera. Esta es una decisión de diseño para evitar la chattiidad de los eventos de salida en la configuración de geovalla (por ejemplo, cuando no se espera que un usuario configure una barrera de salida desde casa para que tenga que recibir una notificación fuera de casa si configura la notificación cuando ya están fuera del hogar). Sin embargo, la plataforma de ubicación podría controlar dónde el controlador GNSS envía eventos de salida, pero no se recomienda porque, después, la interacción entre el adaptador GNSS y el controlador GNSS se convertirá en muy detallado. Dado que las posibilidades de que el usuario escriba una geovalla son mucho más pequeñas que las de fuera de una geovalla, este comportamiento reduce la interacción necesaria entre el controlador GNSS y el adaptador GNSS. Por ejemplo, en el caso de 100 geovallas insertadas en el controlador GNSS, y un usuario estaba fuera de ellos, sin este comportamiento, será necesario enviar a las notificaciones de salida del adaptador GNSS 100. La probabilidad de que ocurra algo similar a esto para los eventos de entrada es muy pequeño.

La transición del estado de geovalla y las alertas asociadas se muestran a continuación. Por motivos de simplicidad, las condiciones de límite de histéresis y geovalla están implícitas.

Los aspectos clave de este diagrama de estado son:

• No se debe generar ninguna alerta al realizar la transición de GNSS_GeofenceState_Unknown a GNSS_GeofenceState_Exited estado.

• Cuando el motor de GNSS no puede realizar un seguimiento de las geovallas en absoluto, es necesario generar una única alerta de estado de seguimiento global, en lugar de una alerta para cada geovalla. El motor de GNSS podría mantener el último estado de conocimiento para cada barrera en lugar de realizar la transición al estado de GNSS_GeofenceState_Unknown, de modo que, cuando sea capaz de realizar un seguimiento de nuevo, se pueden generar las alertas de geovalla necesarias en función de la nueva detección de entrada o salida.

  El mantenimiento de este último estado conocido no es necesario actualmente, ya que una vez que el controlador GNSS genera el evento con gnss_geofences_tracking_status como FAILURE, la plataforma de ubicación en HLOS comenzará a realizar el seguimiento de geovallas. Durante este tiempo, el motor GNSS debe continuar comprobando, de forma optimizada para energía, si se puede realizar un seguimiento de las geovallas de nuevo. El IHV puede usar optimizaciones para realizar esta detección en baja potencia. Entre las técnicas comunes para la optimización se incluyen las siguientes:

  • Retroceso progresivo

  • Esperando señales de bajo costo que son indicativos de movimientos de dispositivos, como datos aceleradores o notificaciones de cambio de telefonía móvil o WiFi.

  • Solicitud de una sesión de seguimiento de distancia de baja precisión desde HLOS mediante las API públicas de WinRT de geolocalización.

  • Comprobaciones de potencia baja para la señal satélite.

  Cuando el motor de GNSS puede realizar un seguimiento de las geovallas de nuevo, se comunica de forma que estableciendo el gnss_geofence_tracking_status como SUCCESS en el adaptador GNSS/HLOS

  El adaptador de GNSS emitirá comandos GNSS_ResetGeofenceTracking y volverá a agregar geovallas activas actualmente con los criterios de entrada y salida actuales de cada geovalla. Esto debe hacerse en caso de que el conjunto de geovallas que se realice el seguimiento ha cambiado o en el estado de cualquier geovalla ha cambiado.

Requisitos

Requisito	Valor
encabezado de	gnssdriver.h