Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Closed 9 years ago.
Improve this question
I was wondering if anyone can explain the flow of an app using core location. I am building a GPS app that will pause (after a given delay set by the user) and then run through the iterations (also set by the user). But I am finding that it runs indefinitely. If I take the for loop out of the code I then get 2 responses back from location manager on my first search.
Effectively this is: user presses the "get location" button. This then calls our getlocation function but it loops twice through this and through the NSLog output I will always see 2 responses but only on the first loop.
Getting location updates is an asynchronous project and you need to wait for, then filter the results. The flow is:
Create a location manager and set your object as it's delegate.
Ask it to start updating your location
Return.
Then you will start receiving location updates. The first one will probably be "stale" (the timestamp on it will be from the last time the GPS was active.) Make your code reject any location update who's timestamp is more than 1/2 second greater than now to solve this problem.
Next, you will receive a series of location updates with really bad (unacceptably bad) horizontal accuracy readings. Check the accuracy reading and reject all readings that are not accurate enough for your purposes. (The accuracy reading is actually a radius value that defines a circle where the location might be, expressed in meters. Smaller is better.)
How accurate is accurate enough depends on your needs. If you can't get an accurate enough reading in a reasonable time (say 30 seconds) make sure you code a timeout that gives up and displays a "can't get an accurate reading" message to the user.
Once you either get a recent reading that's accurate enough, or time out, stop updating until the next time you need a location fix (or keep updating if your app requires that.)
You might want to write a test app that displays timestamps, map positions, accuracy readings, etc as they come in, and then walk around with your phone while it's running. It takes a fair amount of tinkering to get an algorithm that filters location updates the way you need it to.
Related
I am facing issues when using visits monitoring service of coreLocation. When I use visits monitoring, the location update is inconsistent. What exactly is considered as a visit in corelocation?
This is how I start visits monitoring
self.manager.startMonitoringVisits()
I also have added all the CLLocationManagerDelegates.
The documentation is quite ambiguous about what a visit is defined as. As reported by this article
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.
CLVisit has a lot of shortcomings ranging from arrivalDate accuracy to horizontalAccuracy precision.
Instead of relying on CLVisit, try using the Significant Location Change Service
I have an app in the store that uses visit tracking.
I find visit monitoring is pretty accurate. I have never had it detect a red light as a visit, for example. Comparing the reported visit times against an actual record of where I was is also pretty accurate.
The only real inaccuracy I have seen is the actual GPS coordinates and that is more a factor of being indoors or in an inner city area where gps accuracy is reduced.
While Apple does not document how their algorithm works, I suspect that they uses more than just GPS when determining visits; Is the device connected to a car kit? what type of motion occurred prior to and after the "stop" (If motion is smooth and fast before and after you are probably in a vehicle).
One thing to be aware of with visit tracking is that you can receive an initial CLVisit with just an arrival date and then later get an update with the arrival and departure dates filled in.
You can also expect some latency between when you arrive at a location and when you get the initial CLVisit to your delegate, but the arrival date is "back dated" to when iOS determined that the visit started.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I'm learning how to parse JSON from web APIs. I have read that I need to asynchronously return my parsed data from the API for my application, as opposed to synchronously. I'm not sure why it has to be asynchronously. I know it has something to do with threading, but that doesn't clarify it for me.
Why do network requests have to be performed asynchronously?
The fact that you should to do this asynchonously has nothing to do with the nature of the response (JSON or otherwise). It’s just that you’re requesting data from an API on a remote server and you don’t know how long it will take (subject to the nature of the network the device is on, how busy the web server is, etc.).
Bottom line, any task that takes more than a few milliseconds should generally be performed asynchronously to ensure a responsive UI, and this API call will take much more time than that.
Analogy time
Imagine that you're employed in the information booth of a train station to manually update a board with trains' statuses. You read off an old-fashioned ticker tape and move models of the trains around so that passengers can see what's going on. You also answer questions about schedules and such directly, when passengers ask you.
You realize that for one particular portion of the board, some information is missing from your tape. Your colleague has the info, but she isn't in the station. So you leave the board, go over to the phone, and call her. You dial, and wait for her to pick up, and then explain what you need. She doesn't have what you need immediately to hand, so she asks you to wait a moment while she gets it.
Meanwhile, the tape doesn't stop. Information about trains continues to come in. but because you're sitting there on the phone waiting, you're not doing anything with it. The people who are watching the board get frustrated, and the people who have questions for you can't ask them either.
Finally, your colleage comes back and gives you what you asked for. You thank her and return to the board. You realize the board is in very bad shape, not reflecting the current state of the world at all. And the passengers with questions have stormed out and left you a one-star review on the App, I mean Train, Store.
Next day, the same situation comes up. You need information you don't have. Instead of stepping away from the board for several minutes, you quickly fire off a text message, and get right back to talking to passengers and moving things around on the board.
In about the same amount of time that you spent waiting on the phone yesterday, you get a text back from your colleague with the information. You incorporate it into your workflow, and nobody even notices that you spend a couple of seconds reading from your phone instead of the ticker tape. Victory!
The first day, you made a synchronous network request. You initiated a conversation with a remote service and waited until you got the response. When that happened, your UI was locked up, neither taking input from the user nor refreshing its own state.
The second day, you made an asynchronous request. You kept working normally until the response came back, allowing you to continue with all your other tasks.
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.
(This question has been asked before, but the last helpful response is from 2013 and is outdated)
My team is currently working on developing an application that will periodically, every 30 min or so, take a users location and store it. The time intervals that we take a users location is not as important as the accuracy of the location. We are trying to balance battery efficiency with location accuracy. One method that we believe will help with battery efficiency is take users location less frequently during non peak use periods. Other than that after reviewing apples best practice documentation it seams like we may be able to use the Significant Location Change Service to activate the Standard Location Service upon significant location change, but I am not sure how accurate this method will be.
What is the best way to periodically take a users location, while conserving battery life?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Can an iOS app access the time of events using the iOS clock?
This would seem to be a simple question… but couldn’t find anything on Google search or here on Stackoverflow either.
Q1. I’m doing a feasibility study on building an app that needs to record the precise moment an event occurs. For example, if an event in astronomy, nature (e.g. lightning) occurs at 16h18m22s (4:18pm, 22 seconds), and the app supports the user to record when the event occurs, can the exact time the user taps the button be recorded using the iOS clock as a time reference?
Q2. How much precision is offered by the iOS clock? Is it possible to record the event-time as a decimal of one second? Milliseconds?
For example: 16h18m22s50c (where the last two digits represent 50 centiseconds or 0.5 of a second).
Q3. Would it be safe to assume that, apart from timezone differences, that everyone’s iOS device is reading exactly the same time, what one might call "universal device time"?
Q4. Or if this approach using the iOS clock seems a bit clunky, especially where ultra accuracy is required, would it be smarter to get a feed from an atomic clock server?
Thanks for any input on this one. Appreciated!
Cheers
Q1: yes! Using [[NSDate date] timeIntervalSince1970] you get sub-millisecond precision
Q2: you are going to get milliseconds as explained in Q1.
Q3: Since timeIntervalSince1970 gives you exactly what it says (the time interval since 1970), yes - that is a property unaffected of timezones. (watch out for the but below)
Q4: using a server will destroy any way of retrieving an accurate result since you have to contact the server and wait for a response, that will take around 100ms which is far worse than every inaccuracy the device clock would have.
BUT
the user can change its device time which makes the measurement still exact but useless since it no longer reflect the actual time! What you can do in this case is
retrieve the current timestamp of the action on the device
contact a server with a properly set up clock
compare the measurement and ignore the measurement if it is too far off / alert the user to correct his system time. A comparison threshold of half a second should be okay unless your server is very far away or very slow.