tutorial requestwheninuseauthorization manager example current corelocation iphone ios objective-c core-location cllocationmanager

iphone - requestwheninuseauthorization - CLLocationManager geo-fencing/startMonitoringForRegion: vs. startMonitoringForSignificantLocationChanges: vs. start-update de 10 minutos de llamadas



location manager swift tutorial (1)

Estoy tratando de configurar una aplicación que pueda verificar las ubicaciones de las personas en segundo plano, ver si están en una ubicación determinada y enviar un ping a un servidor si lo están. No queremos agotar la energía de nuestros usuarios, por lo que estamos tratando de encontrar la mejor solución.

He leído mucho y no he encontrado mucha información sobre estos métodos. Iré a través de los pros y los contras como los entiendo ahora

startMonitoringForSignificantChanges

Descripción: basado en wi-fi y los cambios de la torre celular, el sistema activa la aplicación.

Docs :

Las aplicaciones pueden esperar una notificación tan pronto como el dispositivo se mueva 500 metros o más de su notificación previa. No debe esperar notificaciones más de una vez cada cinco minutos. Si el dispositivo es capaz de recuperar datos de la red, es mucho más probable que el administrador de ubicación envíe notificaciones de manera oportuna.

Pros:

  • La mayoría de la batería eficiente

Contras:

  • Dependiendo de los cambios de wi-fi / cell tower
  • Solo puede suponer que se llamará cada 200 m a 2 km (si no más en ciertas áreas)
  • Más sobre la precisión
  • Por lo tanto, inconsistente e impreciso.

Actualización de inicio de 10 minutos o " actualización de n minutos":

Descripción: Básicamente, esto le pide a la aplicación más tiempo, cuando ese tiempo adicional está a punto de caducar, llama a [self.locationManager startUpdating], se apodera de la ubicación y extiende el hilo de fondo por 10 minutos más.

Pros:

  • Consistente
  • Puede ser tan preciso como quiera que sea tan consistente como lo desee

Contras:

  • Tiene que hacer una llamada cada diez minutos o menos para que la aplicación se ejecute en segundo plano (es decir, n no puede ser mayor que 10 para las llamadas)

Preguntas: ¿Qué efecto tiene esto en la batería? ¿Despertar el GPS y apagarlo daña más la batería? No podría imaginarme ejecutar una breve verificación de la ubicación en el fondo agotaría mucho la batería ... pero, de nuevo, no sé qué se necesita para encender el GPS y obtener una señal utilizable.

startMonitoringForRegion (geo-fencing):

En pocas palabras, su aplicación se reactiva cuando ingresa a una región predefinida. Este es el bicho raro de ellos, es más reciente y hay menos documentación al respecto. No puedo encontrar una buena descripción de cómo el "sistema monitorea" el cruce de límites. Por lo que sé, es un algoritmo realmente inteligente, o están constantemente haciendo ping al GPS, lo que lo haría menos efectivo que los otros métodos para hacerlo.

Pros:

  • Implementación simple
  • Administrado por el sistema para que no tenga que inventar sus propias geo-cercas ad hoc. Solo se dispara en el cruce de límites ... no hay datos innecesarios que simplemente desechar a cambio de un golpe de batería
  • Por lo tanto, debe ser lo mejor para este tipo de cosas, precisa, gestionada por el sistema.

Contras:

  • La gente cuestiona su efectividad.
  • Enormes conflictos sobre si es o no bueno para la vida útil de la batería o si la batería se agota terriblemente.
  • ¿Cómo está el sistema monitoreando esto?
  • Básicamente, comportamiento indeterminado.

Supongo que mi pregunta se reduce a cómo startMonitoringForRegion: se compara con estos otros métodos para probar la ubicación del usuario en segundo plano cuando se trata de la duración, la consistencia y la precisión de la batería. ¿Alguien ha probado a fondo esto? ¿O lo usó en su aplicación y obtuvo al menos algunos comentarios? Probablemente, para mis propósitos, la compensación es entre geo-cercas y el método de actualización de 10 minutos. (También dado lo que Apple ha dicho públicamente acerca de iOS7, habrá algunas tareas de fondo ... ¿cambiará esto el cálculo para la compensación entre estos dos métodos?) ¿Alguien tiene una idea de cómo se comparan estos dos?

¡Muchas gracias! Espero ver si podemos llegar al fondo de cómo comparar estos métodos.


Llevo 2 años trabajando en el rastreo de vehículos con GPS. Aprendí mucho de la manera difícil ... En mi experiencia startMonitoringForRegion o Geo-fencing depende de los eventos de cambio de celda, los eventos didEnter o didExit no se activan hasta que hay un evento de cambio de celda / wifi. Por lo tanto, no hay ninguna diferencia entre el consumo de batería. Sin embargo, realiza cálculos adicionales que dependen de cuántas regiones se estén monitoreando actualmente. Incluso la aplicación Recordatorio de Apple no da buenos resultados para los recordatorios basados ​​en la ubicación porque utiliza geo-cercas.

El otro método para iniciar el GPS durante n minutos después de cada m-minutos es una buena opción, no debería afectar la vida útil de la batería, si se hace con prudencia. Lo que afecta exactamente a la batería es la activación constante del GPS en modo de alta precisión. Como, por ejemplo, si habilita el GPS con kCLLocationAccuracyBest y distance-filter = 0, literalmente puede observar el drenaje de la batería y pronto su dispositivo también comenzará a calentarse.

Si fuera usted, me gustaría activar el GPS cada 10 minutos durante 5 segundos con kCLLocationAccuracyBest (o puede que kCLLocationAccuracyNearestTenMeters use menos batería, si la precisión no es tan importante) y el filtro de distancia = 5 (metros). El consumo de batería en este caso será imperceptible. Puedes jugar con configuraciones similares que pueden abordar tu caso específico y finalmente descubrir cuál es la mejor para ti.

Por cierto: el iPhone usa AGPS, A-GPS, además, utiliza recursos de red para localizar y usar los satélites en condiciones de señal deficientes. Por lo tanto, cuando inicia startUpdatingLocation, también utilizará la información de la torre celular cercana. ver http://en.wikipedia.org/wiki/Assisted_GPS