P粉7757887232023-08-28 09:08:27
I have a partial answer, but unfortunately not a complete answer.
First, realize that the default timeout for getCurrentPosition is infinite(!). This means that if getCurrentPosition hangs somewhere on the backend, your error handler will never be called.
To ensure timeouts, add an optional third parameter to the call to getCurrentPosition, for example, if you want the user to wait no more than 10 seconds before being prompted what happened, use: p>
navigator.geolocation.getCurrentPosition(successCallback,errorCallback,{timeout:10000});
Secondly, I have experienced completely different reliability in different environments. At home, I would receive a call back within a second or two, although the accuracy was poor.
However, at work I experience a rather strange change in behavior: geolocation works all the time on some computers (except IE, of course), others only works in chrome and safari, but not in Firefox works (gecko issue?), other computers only work once and then fail - this pattern changes hourly and daily. Sometimes you have a "lucky" computer, sometimes you don't. Maybe slaughtering the goat during the full moon would help?
I can't understand this, but I suspect that the backend infrastructure is more unbalanced than is advertised in the various enthusiast books and websites pushing this feature. I really wish they'd been more direct about how unstable this feature is and how important the timeout setting is if you want your error handler to work properly.
I've been trying to teach these to students today and ran into the embarrassing situation of my own computer (on a projector and several large screens) silently failing while about 80% of the students Getting an almost instant result (using the exact same wireless network). When my students also make typos and other mistakes, and when my own computer malfunctions, it's very difficult to fix these problems.