I am working on a app that relies heavily on monitoring user visits in possibly multiple regions / areas. I am currently experimenting with region monitoring which works pretty well, however, the location callback is not as accurate as I want it to be. I have seen CLVisit, but the documentation out there doesnt explain it very well, especially its use.
I think you are misunderstanding the concept of CLVisits. There is actually no Visit object that you need to create. The CLLocationManager delegate method is triggered by the algorithm that apple has determined (see wwdc lecture for more info). This is explained in the CLLocationManager documentation...
Getting the Visited Locations
In iOS, the visits service provides an alternative to the significant location change service for apps that need location information about interesting places that the user visited. For example, if the user is in one location for an extended period of time, the service might generate an event when the user arrives at that location and another when the user leaves that location. The service is intended for apps that might already be using the significant location change service and want an even lower power way to do so. You would not use this service to create navigation apps or apps that rely on regular location updates.
To begin the delivery of visit-related events, assign a delegate to the location manager object and call its startMonitoringVisits method. As the location manager generates visit events, it delivers that information to its delegate’s locationManager:didVisit: method. The event data delivered to your delegate includes only the information that occurred after you started the delivery of events. In other words, if you start the delivery of events after the user arrived at an interesting location, the event delivered by the system when the user departed that location would not reflect the actual arrival time. If the system terminates your app, this service relaunches it when new visit events are ready to be delivered.
That said if you look at this article from NSHipster, it references some current issues with CLVists (for iOS 8.1). It essentially goes on to say that if you want infrastructure that extremely precise don't use CLVisit. Seems like you're doing it right (for now at least).
CLVisit is, as of iOS 8.1, not all that precise. While start and end times are
generally accurate within a minute or two, lines get blurred at the edges of
what is and what is not a visit. Ducking into a corner coffee shop for a minute
might not trigger a visit, but waiting at a particularly long traffic light
might. It’s likely that Apple will improve the quality of visit detection in
future OS upgrades, but for now you might want to hold off on relying on CLVisit
in favor of your own visit detection for use cases where it’s vital your data is
as accurate as it can be.
Related
My question involves keeping an app that monitors user interactions in the background, for example time spent in one or the app. The issue arises when you can not have a background process run for more than 10 min or violate Apple's sandbox restrictions. Since I am relatively new to the Apple API, and could not find a direct answer that didn't involve location services or VOIP (which are both interesting options, but my application will not be able to use either viably), I come to ask for options in which I can understand when another app opens, when it closes, when it fetches data, and when user holds phone in certain orientation (ie when people hold their phone at certain angles to read text and etc.) for certain amount of time.
The purpose of this analyzation is to predict an attention span for the user, so I need to be able to run in the background, as the user will not be using my app while it predicts attention span.
My thoughts on this are possibly accessing the system log, and somehow parse previous statements (I don't think sandbox will allow), but inevitably the iOS system will suspend my processes after some point unless I put a timer. There is also the option of having the system wake up my app via opportunistic fetching, but that won't be useful if I don't collect the data.
Keep in mind this is within IOS 11, so it is much more restrictive than previous iterations. I understand this may seem like a complex problem, but even a direction in which to head could be useful to me.
This solution might work, (not recommended since it drains the battery quicker).
Just update your current location, every 10 mins. It will reset the background thread timer.
We use significant-location-change monitoring to know about our user's whereabouts when the app is not running. This data is based on cellular towers signals and therefore is not very accurate. We would like to use more accurate data whenever it is possible, that is, when the app is active or running in the background.
The question is, should I use "startMonitoringSignificantLocationChanges" and "startUpdatingLocation" at the same time, or, should I switch between those two methods? And if the second option is better, what app delegate events should I use in order to perform the necessary switch?
Unless you want to support a feature that needs continuous high precision location stream, its best to avoid using the high accuracy GPS data via startUpdatingLocation all the time.
I understand from your question that you intend to use more accurate location only at certain points of interest, when your app is woken up. In that case, the second approach of switching-on the more accurate location data only when needed, would be a better idea.
locationManager(_:didUpdateLocations:) in your CLLocationManager delegate would be a good point to start this in your case. Remember that significant location change monitoring API wakes up the system at least once every 15 minutes, even if there are no location changes, until it is explicitly stopped. So one must use it with care.
Instrumenting accurate location tracking while making sure that you don't eat up all of the phone battery is a non-trivial problem to solve. You may want to give third party SDKs like Hypertrack, which specialise in this, a try.
The app I'm working on records information about places where user spends most of his/her time. Core Location's Visits monitoring fulfil all it's requirements in location information absolutely.
While testing this app our QA-engineers revealed evidence that Core Location misses Visits for unknown reason. And this is not a result of low location accuracy. Core Location starts skipping locations registered before without any problems.
To make things clear we've run the test. I installed on his phone our app and example app: https://github.com/steveschauer/TestCLVisit
After 3 days of testing we compared locations from our app, sample app and information from Settings->Privacy->Location Services->System Services->Frequent Locations.
Information from all sources was equal. So we can say that it's not an issue of our app.
But while all locations registered at first day was correct, many locations of second and third day were missed. Only few of them were registered.
Is it normal behaviour for Visits Monitoring?
What could be a reason of such skips?
Does anybody have negative or positive experience of Visits monitoring?
Yes, I faced some similar issues while using CLVisit API. There is also an article from NSHipster, which describe some issues with CLVists and these are still present in iOS 10. It essentially goes on to say that if you want infrastructure that extremely precise don't use CLVisit.
From our experience, CLVisit is not all that precise. While start and end times are generally accurate within a minute or two, lines get blurred at the edges of what is and what is not a visit. Ducking into a corner coffee shop for a minute might not trigger a visit, but waiting at a particularly long traffic light might.
for an app that is part of a scientific study I have to implement location tracking (the users who take part in the study know this and are willing to supply this data). The two premises for this app are:
track the user's location with the highest accuracy possible while he/she is on the move
use as little power as possible so that users don't feel the need to shut down the app (turn off location services for it), while they aren't using it
I know these two requirements normally exclude each other :) So the general question is "What would be the best strategy to meet in the middle here?"
My thoughts were to monitor as usual with the highest accuracy possible while location changes keep coming in. If we detect that the delta between theses location updates become almost 0 over a certain period of time, we would assume that the user is not "on the move" anymore and would switch to region monitoring (with a radius of e.g. 40m). Once the user exits that region we'd switch back to regular location monitoring.
So two questions:
Can you tell me if the proposed approach will work for an app that is running in the background?
Have you maybe implemented something similar and know if it really saves a lot of battery power?
Regards,
Sebastian
My thoughts were to monitor as usual with the highest accuracy possible while location changes keep coming in. If we detect that the delta between theses location updates become almost 0 over a certain period of time, we would assume that the user is not "on the move" anymore and would switch to region monitoring (with a radius of e.g. 40m). Once the user exits that region we'd switch back to regular location monitoring.
Using region monitoring to re-engage the location monitoring has a few draw backs, that I have found:
If you set up a region for the user's current location, then wait for -didExitRegion to fire, you're reliant upon the system's default radius cushion, (probably 200m) and some time (probably 20 sec) after they cross out of their boundary before you'll get the message. If accuracy is your main goal, you're likely to loose a lot of data points in between when region monitoring started and when you cross out of the region. Is that acceptable for your needs?
So, to answer your questions:
Can you tell me if the proposed approach will work for an app that is running in the background?
You should not have any trouble running this type of thing in the background. Both location monitoring and region monitoring work when an app is backgrounded, provided you've set it up to do so. Also, to ensure Region Monitoring works on iOS 7 you must have Background App Refresh turned on for your app. That tripped me up.
Have you maybe implemented something similar and know if it really saves a lot of battery power?
In our experience the battery savings were not noticeable. Region Monitoring can be a battery drain that's just as significant as the high accuracy location updates because it uses all kinds of hardware to do it's thing. So pick your poison. Apple's recommendation for saving battery is and always has been to use the significant change location service. It gives you good location data just not as often.
I am currently using significant location change updates to monitor whether or not the user has entered a particular area of interest (my definition of an area of interest is more broad than can be defined simply by geographic regions). My requirements are that my app should be woken up periodically to check if the user is said defined area (if it is not currently running).
My question is: would registering for region updates (since I have a number of regions that are known to fit my area of interest), provide me with more updates than simply listening for all significant lcoation changes, or would they simply be duplicate updates? The reason I ask this question is to clairify whether or not region monitoring is simply a filter on significant location change updates (since neither are documented as powering the GPS), or if region monitoring somehow is able to be more specific (maybe it powers the GPS, but with more specificity). In particular, I would be interested to know if anyone has seen data or documentation on this issue.
Thanks.
Region monitoring seems to pull from more specific location signal changes than the significant location change service. I say this because I've defined small regions (~100 m radius) that region monitoring picks up in the background, but that Significant location change does not. However please remember that the two events are triggered on different types of user actions.
Region monitoring - triggered on boundary crossings only. So a user must have two location update events on either side of the boundary. If you define large regions and the user walks around inside of them you will get no updates.
Significant location change - Seems to be triggered on the phone switching cell towers and the Location Awareness docs seem to suggest that. Here is some great data on general accuracy of these updates that suggests about 500 m between notification.