Apache Cordova
  1. Apache Cordova
  2. CB-95

.watchPosition & .getCurrentPosition still timeouts

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.8.0
    • Component/s: iOS
    • Labels:
      None

      Issue Links

        Activity

        Hide
        Filip Maj added a comment -

        Neither timeout now. I think this is resolved.

        Show
        Filip Maj added a comment - Neither timeout now. I think this is resolved.
        Hide
        Shazron Abdullah added a comment -

        This needs to be re-tested with the totally new geolocation implementation of 1.6.0 coming week of April 9th 2012.

        Show
        Shazron Abdullah added a comment - This needs to be re-tested with the totally new geolocation implementation of 1.6.0 coming week of April 9th 2012.
        Hide
        Steven Romalewski added a comment -

        As far as I can tell, adding
        [self.locationManager stopUpdatingLocation];
        to Location.m doesn't fix anything. (This is @mschulkind's fix for #197 above.) Unless I'm doing something wrong, when I rebuild Phonegap 1.1.0 after adding this line, watchPosition still fails to get a position on subsequent calls (it works the first time, but then if I call it again, it doesn't fire at all and I have to rely on setting a timeout in order to force my app to get a position).

        I'm going back to @paulj 's approach of adding "this.stop()" to phonegap.js. Even though this keeps calling watchPosition and therefore wasting battery power (even though I've cleared the watchID), at least it seems to force watchPosition to behave like it should.

        But "[self.locationManager stopUpdatingLocation];" doesn't seem to have any affect at all.

        Show
        Steven Romalewski added a comment - As far as I can tell, adding [self.locationManager stopUpdatingLocation] ; to Location.m doesn't fix anything. (This is @mschulkind's fix for #197 above.) Unless I'm doing something wrong, when I rebuild Phonegap 1.1.0 after adding this line, watchPosition still fails to get a position on subsequent calls (it works the first time, but then if I call it again, it doesn't fire at all and I have to rely on setting a timeout in order to force my app to get a position). I'm going back to @paulj 's approach of adding "this.stop()" to phonegap.js. Even though this keeps calling watchPosition and therefore wasting battery power (even though I've cleared the watchID), at least it seems to force watchPosition to behave like it should. But " [self.locationManager stopUpdatingLocation] ;" doesn't seem to have any affect at all.
        Hide
        Shazron Abdullah added a comment -

        by: http://github.com/gregavola (2011-10-27T14:03:23Z)

        As I have mentioned in all those issues listed above - I am experiencing this issue. The only way to work around this:

        1. The first call to get the location, works if the app has just been started for the first time. You'll need to cache the location (you can use LocalStorage), and then store the timeStamp of when that location was pulls.
        2. Since every subsequent call to get the location fails, use the cached location to make the call. You can also use the timeStamp to check the age of the lat/long. If the timeStamp is very old - you can force and update, but in your callback make sure you do the following:

        function err_callback(err)
        {
        if (err.code == 3)

        { // its timeout error. use the localstorage elements and tell the user of the issue. }

        else

        { // its a real error! }

        }

        It's the only way to currently work around the frustration of the issue.

        Thanks,
        Greg

        by: http://github.com/sromalewski (2011-10-27T14:07:55Z)

        Thanks @gregavola, I'll try your workaround.

        Since geo is such a fundamental aspect of mobile (using your phone to determine your location and then doing interesting/cool things with that location), it makes me wonder what kind of apps people are writing now with Phonegap, since geo hasn't worked now for the last two PG versions. I'd expect more of an outcry from devs about this, unless they're just writing relatively simple apps, or perhaps games. What do you think?

        by: http://github.com/gregavola (2011-10-27T14:15:25Z)

        @sromalewski I have no idea why it hasn't been addresses - as it's one of those features that works perfectly fine WITHOUT an Native App - so I figure it would be an important feature.

        I've been told it has to do with a timeout with the native Objective-C code. Hopefully a PG dev can fix this soon!

        by: http://github.com/paulj (2011-11-01T11:06:05Z)

        I've been seeing this in my application, though it varies by device and location. My device in Australia isn't seeing it, but I've got ones in the UK that do.

        I've managed to fix the problem by inserting a `this.stop()` directly above the `this.start(params)` in the `Geolocation.prototype.getCurrentPosition` definition. My figuring on this (after reading the iOS location manager docs) is that PhoneGap's location is expiring because the location manager hasn't issue an update during the timeout, and the call to startLocation in the native code does nothing to provoke a new one being sent. Calling stop beforehand ensures that the location manager provides a new location update.

        This doesn't seem like a permanent fix to me though - I'm wondering why the location values are expired in getCurrentPosition at all. Whenever the location services are running, they should be being kept up to date - so in what scenario would they become stale?

        by: http://github.com/sromalewski (2011-11-01T11:20:01Z)

        Great suggestion, I'll test this fix and post how well it worked. Btw, do you have a sense if this will work for watchPosition as well? (I don't have the code in front of me.) Thanks!

        by: http://github.com/paulj (2011-11-01T11:21:08Z)

        @sromalewski watchPosition is calling getPosition internally, so I reckon it should help.

        by: http://github.com/sromalewski (2011-11-01T13:46:56Z)

        @paulj I tried your suggestion and here's the result. Short answer is I think it worked. My app now calls watchPosition like it should - in other words, when I call watchPosition subsequent times after the first one, it does indeed try to get a position instead of timing out.

        My code is below, and the console result is below that.

        I have a function "nearMe" that my users can call by tapping on a screen element (I use the Datazombies fork of jQTouch for my UI). I've added comments below to annotate the code:

        function nearMe(){
        lmNS.gotcoordsFlag = false; // I create a namespace 'lmNS' so I can reuse variables across multiple functions.

        console.log('****** STARTING LAT LON ' + lmLat + ', ' + lmLon);
        var geoOptions =

        { maximumAge: 1000, enableHighAccuracy: true }

        ;

        lmNS.watchID = navigator.geolocation.watchPosition(onGeoUpdateSuccess, onGeoUpdateError, geoOptions);
        console.log('****** WATCH ID ' + lmNS.watchID);

        lmNS.timerFlag = false;
        lmNS.t = setTimeout(getCoordTimeout,7000);
        }

        function onGeoUpdateSuccess(position) {
        lmLat = position.coords.latitude;
        lmLon = position.coords.longitude;
        lmNS.lmAccuracy = position.coords.accuracy;

        console.log('******Coords are ' + lmLat + ' and ' + lmLon + '; Accuracy ' + lmNS.lmAccuracy);

        // I use gotCoordsFlag to solve problem of watchPosition trying to sneak in another success callback after we've gotten coords
        if (lmNS.gotcoordsFlag === false){
        if (lmNS.watchID != null){
        if (lmNS.lmAccuracy <= 70)

        { console.log('****** LESS THAN 70 ACCURACY'); lmNS.timerFlag = true; navigator.geolocation.clearWatch(lmNS.watchID); lmNS.watchID = null; lmNS.lmAccuracy = null; lmNS.locSource = 'GPS'; lmNS.mapViewFlag = ''; lmNS.gotcoordsFlag = true; useNearMeCoords(); }


        }
        }
        }

        function getCoordTimeout(){
        console.log('******** TIMEOUT Lat is ' + lmLat);

        if (lmNS.timerFlag != true && lmLat != 0)

        { console.log('****WATCH OFF VIA TIMEOUT**** USING PRIOR OR LOWER QUALITY COORDS and Accuracy is ' + lmNS.lmAccuracy); lmNS.lmAccuracy = null; lmNS.locSource = 'GPS'; lmNS.mapViewFlag = ''; lmNS.gotcoordsFlag = true; useNearMeCoords(); }

        else if (lmNS.timerFlag != true && lmLat === 0)

        { console.log('****We\'re trying again.'); nearMe(); }

        }

        The first time I call nearMe, watchPosition almost always returns a lat/lon with accuracy better than 70 meters. (Note that I'm testing this on my iPhone 3GS running iOS 4.3.3.) Before implementing your "this.stop()" fix, when I would call nearMe subsequent times, the watchPosition success or failure callbacks would almost never be invoked and I would always have to rely on the timeout (i.e., the app would be using old coordinates until watchPosition would eventually fire and get newer, better coordinates).

        After I implemented your fix, here's my console output (I tapped the nearMe screen element the first time, then I moved about 50 feet and tapped again, then moved to a different spot and tapped again).

        Nov 1 09:19:22 unknown GeoLocTest[5525] : Device initialization: DeviceInfo = {"name":"Sromalewski’s iPhone","uuid":"xxxxxxxx","platform":"iPhone","gap":"1.1.0","version":"4.3.3","connection":{"type":"wifi"}};
        Nov 1 09:19:25 unknown GeoLocTest[5525] : [INFO] ****** STARTING LAT LON 0, 0
        Nov 1 09:19:25 unknown GeoLocTest[5525] : [INFO] ****** WATCH ID 13
        Nov 1 09:19:25 unknown GeoLocTest[5525] : Received memory warning. Level=1
        Nov 1 09:19:25 unknown GeoLocTest[5525] : [INFO] ******Coords are 40.744286 and -73.998093; Accuracy 66.01
        Nov 1 09:19:25 unknown GeoLocTest[5525] : [INFO] ****** LESS THAN 70 ACCURACY
        Nov 1 09:19:25 unknown GeoLocTest[5525] : [INFO] ***** GOT COORDS
        Nov 1 09:19:25 unknown GeoLocTest[5525] : Loading stop
        Nov 1 09:19:27 unknown GeoLocTest[5525] : Loading stop
        Nov 1 09:19:30 unknown GeoLocTest[5525] : [INFO] ********** Flags: locSource GPS, mapView , gotCoords true
        Nov 1 09:19:32 unknown GeoLocTest[5525] : [INFO] ******** TIMEOUT Lat is 40.744286 //The timeout is reached, but because the timeFlag is true the timeout if statement isn't invoked.
        Nov 1 09:20:07 unknown GeoLocTest[5525] : [INFO] ****** STARTING LAT LON 40.744286, -73.998093 //This is the second activation of nearMe.
        Nov 1 09:20:07 unknown GeoLocTest[5525] : [INFO] ****** WATCH ID 16
        Nov 1 09:20:14 unknown GeoLocTest[5525] : [INFO] ******** TIMEOUT Lat is 40.744286
        Nov 1 09:20:14 unknown GeoLocTest[5525] : [INFO] ***WATCH OFF VIA TIMEOUT*** USING PRIOR OR LOWER QUALITY COORDS and Accuracy is null //The fact that lmNS.lmAccuracy is null says to me that the watchPosition success callback wasn't fired, but neither was the failure callback.
        Nov 1 09:20:14 unknown GeoLocTest[5525] : [INFO] ***** GOT COORDS
        Nov 1 09:20:14 unknown GeoLocTest[5525] : Loading stop
        Nov 1 09:20:17 unknown GeoLocTest[5525] : Loading stop
        Nov 1 09:20:17 unknown GeoLocTest[5525] : [INFO] ********** Flags: locSource GPS, mapView , gotCoords true
        Nov 1 09:20:27 unknown GeoLocTest[5525] : [INFO] ******Coords are 40.744316 and -73.998142; Accuracy 65 //But this indicates that the watchPosition success callback was eventually fired. Except that I didn't use the coords because the gotCoordsFlag had already been set to true. Maybe I need to tweak the timing of maximumAge?
        Nov 1 09:20:36 unknown GeoLocTest[5525] : [INFO] ****** STARTING LAT LON 40.744316, -73.998142 //This is the third activation of nearMe.
        Nov 1 09:20:36 unknown GeoLocTest[5525] : [INFO] ****** WATCH ID 19
        Nov 1 09:20:37 unknown GeoLocTest[5525] : [INFO] ******Coords are 40.744301 and -73.998089; Accuracy 93.36
        Nov 1 09:20:43 unknown GeoLocTest[5525] : [INFO] ******** TIMEOUT Lat is 40.744301
        Nov 1 09:20:43 unknown GeoLocTest[5525] : [INFO] ***WATCH OFF VIA TIMEOUT*** USING PRIOR OR LOWER QUALITY COORDS and Accuracy is 93.36
        Nov 1 09:20:43 unknown GeoLocTest[5525] : [INFO] ***** GOT COORDS
        Nov 1 09:20:43 unknown GeoLocTest[5525] : Loading stop
        Nov 1 09:20:46 unknown GeoLocTest[5525] : Loading stop
        Nov 1 09:20:46 unknown GeoLocTest[5525] : [INFO] ********** Flags: locSource GPS, mapView , gotCoords true
        Nov 1 09:20:56 unknown GeoLocTest[5525] : [INFO] ******Coords are 40.744327 and -73.998137; Accuracy 65 //Again, these lines are indications that the watchPosition success callback is being fired multiple times, which (AFAIK) is how the function is supposed to work now that your I implemented this.stop() fix. (Actually, it keeps getting fired - I need to tweak how I clear the watchID to minimize battery impact.)
        Nov 1 09:20:57 unknown GeoLocTest[5525] : [INFO] ******Coords are 40.744327 and -73.998137; Accuracy 65

        Sorry for the lengthy code and console entries, but hopefully this is helpful. What do you think? Thanks!

        by: http://github.com/sromalewski (2011-11-01T15:11:21Z)

        Success! I've been testing my app in the field all morning, and watchPosition with repeated calls works just great - indoors, outdoors, with wifi, without wifi. I'll check my console log tonight when I'm back home, but for now I'm thrilled. Thanks @paulj !

        by: http://github.com/sromalewski (2011-11-02T13:36:27Z)

        I've done some more testing, and checked my console log entries, and I think there's still a (or perhaps new) problem. Unless I haven't set up my code properly, I can't seem to clear the watchID after I've added @paulj 's "this.stop()" fix. Even though I've cleared the watchID and set it to null, every time I move my phone (even a few feet) the watchPosition success callback is called again and again.

        I even added a flag that's set to true after I get the coordinates, and watchPosition is still called:

        if (lmNS.gotcoordsFlag === false)

        { lmNS.watchID = navigator.geolocation.watchPosition(onGeoUpdateSuccess, onGeoUpdateError, geoOptions); }

        This doesn't seem to have any effect, watchPosition is called repeatedly even though lmNS.gotcoordsFlag has been set to true. And in my onGeoUpdateSuccess, the first line is the following:

        console.log('****** WATCH ID ' + lmNS.watchID);

        It returns:
        Nov 2 09:35:09 unknown GeoLocTest[6139] : [INFO] ****** WATCH ID null

        So the watchID is null and gotcoordsFlag is true, but watchPosition is still being called. I'm mystified.

        by: http://github.com/gregavola (2011-11-07T15:06:01Z)

        @sromalewski so it seems like there still is a bug with watchPosition? What about getPosition - does that appear to be fixed with this.stop();?

        by: http://github.com/sromalewski (2011-11-24T04:35:37Z)

        Not sure about getCurrentPosition. But I've implemented @paulj 's fix and it seems to work. Not ideal, but it's good enough for Apple – my app update with the fix was accepted for iTunes and is now in the AppStore (see http://spatialityapps.com/). It still seems buggy, but for now it's adequate.

        Btw, @mschulkind has a similar fix, but it didn't seem to provide anything different from paulj's fix – see https://github.com/phonegap/phonegap-iphone/issues/197#issuecomment-2741229 Odd that it's so problematic but isn't really being addressed head on.

        Several people have raised the issue recently on Google Groups: see http://groups.google.com/group/phonegap/browse_thread/thread/90e7eee2798b8bb2# and http://groups.google.com/group/phonegap/browse_thread/thread/1b8bd1e4716b0994#

        by: http://github.com/shazron (2011-11-24T20:46:56Z)

        Does this fix it? https://github.com/callback/callback-ios/pull/14 (already pulled into trunk)

        by: http://github.com/sromalewski (2011-11-28T05:36:31Z)

        Thanks @shazron. I'm reluctant to test this, though, because I'm not ready to upgrade to PG 1.2. Can I simply run the install with 1.2, add phonegap-1.2.0.js to my existing www folder, then build my app? I'm worried I'll run into problems, and then have to start from scratch by creating a new project and then manually importing all the plugins, etc.

        Show
        Shazron Abdullah added a comment - by: http://github.com/gregavola (2011-10-27T14:03:23Z) As I have mentioned in all those issues listed above - I am experiencing this issue. The only way to work around this: 1. The first call to get the location, works if the app has just been started for the first time. You'll need to cache the location (you can use LocalStorage), and then store the timeStamp of when that location was pulls. 2. Since every subsequent call to get the location fails, use the cached location to make the call. You can also use the timeStamp to check the age of the lat/long. If the timeStamp is very old - you can force and update, but in your callback make sure you do the following: function err_callback(err) { if (err.code == 3) { // its timeout error. use the localstorage elements and tell the user of the issue. } else { // its a real error! } } It's the only way to currently work around the frustration of the issue. Thanks, Greg by: http://github.com/sromalewski (2011-10-27T14:07:55Z) Thanks @gregavola, I'll try your workaround. Since geo is such a fundamental aspect of mobile (using your phone to determine your location and then doing interesting/cool things with that location), it makes me wonder what kind of apps people are writing now with Phonegap, since geo hasn't worked now for the last two PG versions. I'd expect more of an outcry from devs about this, unless they're just writing relatively simple apps, or perhaps games. What do you think? by: http://github.com/gregavola (2011-10-27T14:15:25Z) @sromalewski I have no idea why it hasn't been addresses - as it's one of those features that works perfectly fine WITHOUT an Native App - so I figure it would be an important feature. I've been told it has to do with a timeout with the native Objective-C code. Hopefully a PG dev can fix this soon! by: http://github.com/paulj (2011-11-01T11:06:05Z) I've been seeing this in my application, though it varies by device and location. My device in Australia isn't seeing it, but I've got ones in the UK that do. I've managed to fix the problem by inserting a `this.stop()` directly above the `this.start(params)` in the `Geolocation.prototype.getCurrentPosition` definition. My figuring on this (after reading the iOS location manager docs) is that PhoneGap's location is expiring because the location manager hasn't issue an update during the timeout, and the call to startLocation in the native code does nothing to provoke a new one being sent. Calling stop beforehand ensures that the location manager provides a new location update. This doesn't seem like a permanent fix to me though - I'm wondering why the location values are expired in getCurrentPosition at all. Whenever the location services are running, they should be being kept up to date - so in what scenario would they become stale? by: http://github.com/sromalewski (2011-11-01T11:20:01Z) Great suggestion, I'll test this fix and post how well it worked. Btw, do you have a sense if this will work for watchPosition as well? (I don't have the code in front of me.) Thanks! by: http://github.com/paulj (2011-11-01T11:21:08Z) @sromalewski watchPosition is calling getPosition internally, so I reckon it should help. by: http://github.com/sromalewski (2011-11-01T13:46:56Z) @paulj I tried your suggestion and here's the result. Short answer is I think it worked. My app now calls watchPosition like it should - in other words, when I call watchPosition subsequent times after the first one, it does indeed try to get a position instead of timing out. My code is below, and the console result is below that. I have a function "nearMe" that my users can call by tapping on a screen element (I use the Datazombies fork of jQTouch for my UI). I've added comments below to annotate the code: function nearMe(){ lmNS.gotcoordsFlag = false; // I create a namespace 'lmNS' so I can reuse variables across multiple functions. console.log('****** STARTING LAT LON ' + lmLat + ', ' + lmLon); var geoOptions = { maximumAge: 1000, enableHighAccuracy: true } ; lmNS.watchID = navigator.geolocation.watchPosition(onGeoUpdateSuccess, onGeoUpdateError, geoOptions); console.log('****** WATCH ID ' + lmNS.watchID); lmNS.timerFlag = false; lmNS.t = setTimeout(getCoordTimeout,7000); } function onGeoUpdateSuccess(position) { lmLat = position.coords.latitude; lmLon = position.coords.longitude; lmNS.lmAccuracy = position.coords.accuracy; console.log('******Coords are ' + lmLat + ' and ' + lmLon + '; Accuracy ' + lmNS.lmAccuracy); // I use gotCoordsFlag to solve problem of watchPosition trying to sneak in another success callback after we've gotten coords if (lmNS.gotcoordsFlag === false){ if (lmNS.watchID != null){ if (lmNS.lmAccuracy <= 70) { console.log('****** LESS THAN 70 ACCURACY'); lmNS.timerFlag = true; navigator.geolocation.clearWatch(lmNS.watchID); lmNS.watchID = null; lmNS.lmAccuracy = null; lmNS.locSource = 'GPS'; lmNS.mapViewFlag = ''; lmNS.gotcoordsFlag = true; useNearMeCoords(); } } } } function getCoordTimeout(){ console.log('******** TIMEOUT Lat is ' + lmLat); if (lmNS.timerFlag != true && lmLat != 0) { console.log('****WATCH OFF VIA TIMEOUT**** USING PRIOR OR LOWER QUALITY COORDS and Accuracy is ' + lmNS.lmAccuracy); lmNS.lmAccuracy = null; lmNS.locSource = 'GPS'; lmNS.mapViewFlag = ''; lmNS.gotcoordsFlag = true; useNearMeCoords(); } else if (lmNS.timerFlag != true && lmLat === 0) { console.log('****We\'re trying again.'); nearMe(); } } The first time I call nearMe, watchPosition almost always returns a lat/lon with accuracy better than 70 meters. (Note that I'm testing this on my iPhone 3GS running iOS 4.3.3.) Before implementing your "this.stop()" fix, when I would call nearMe subsequent times, the watchPosition success or failure callbacks would almost never be invoked and I would always have to rely on the timeout (i.e., the app would be using old coordinates until watchPosition would eventually fire and get newer, better coordinates). After I implemented your fix, here's my console output (I tapped the nearMe screen element the first time, then I moved about 50 feet and tapped again, then moved to a different spot and tapped again). Nov 1 09:19:22 unknown GeoLocTest [5525] : Device initialization: DeviceInfo = {"name":"Sromalewski’s iPhone","uuid":"xxxxxxxx","platform":"iPhone","gap":"1.1.0","version":"4.3.3","connection":{"type":"wifi"}}; Nov 1 09:19:25 unknown GeoLocTest [5525] : [INFO] ****** STARTING LAT LON 0, 0 Nov 1 09:19:25 unknown GeoLocTest [5525] : [INFO] ****** WATCH ID 13 Nov 1 09:19:25 unknown GeoLocTest [5525] : Received memory warning. Level=1 Nov 1 09:19:25 unknown GeoLocTest [5525] : [INFO] ******Coords are 40.744286 and -73.998093; Accuracy 66.01 Nov 1 09:19:25 unknown GeoLocTest [5525] : [INFO] ****** LESS THAN 70 ACCURACY Nov 1 09:19:25 unknown GeoLocTest [5525] : [INFO] ***** GOT COORDS Nov 1 09:19:25 unknown GeoLocTest [5525] : Loading stop Nov 1 09:19:27 unknown GeoLocTest [5525] : Loading stop Nov 1 09:19:30 unknown GeoLocTest [5525] : [INFO] ********** Flags: locSource GPS, mapView , gotCoords true Nov 1 09:19:32 unknown GeoLocTest [5525] : [INFO] ******** TIMEOUT Lat is 40.744286 //The timeout is reached, but because the timeFlag is true the timeout if statement isn't invoked. Nov 1 09:20:07 unknown GeoLocTest [5525] : [INFO] ****** STARTING LAT LON 40.744286, -73.998093 //This is the second activation of nearMe. Nov 1 09:20:07 unknown GeoLocTest [5525] : [INFO] ****** WATCH ID 16 Nov 1 09:20:14 unknown GeoLocTest [5525] : [INFO] ******** TIMEOUT Lat is 40.744286 Nov 1 09:20:14 unknown GeoLocTest [5525] : [INFO] *** WATCH OFF VIA TIMEOUT *** USING PRIOR OR LOWER QUALITY COORDS and Accuracy is null //The fact that lmNS.lmAccuracy is null says to me that the watchPosition success callback wasn't fired, but neither was the failure callback. Nov 1 09:20:14 unknown GeoLocTest [5525] : [INFO] ***** GOT COORDS Nov 1 09:20:14 unknown GeoLocTest [5525] : Loading stop Nov 1 09:20:17 unknown GeoLocTest [5525] : Loading stop Nov 1 09:20:17 unknown GeoLocTest [5525] : [INFO] ********** Flags: locSource GPS, mapView , gotCoords true Nov 1 09:20:27 unknown GeoLocTest [5525] : [INFO] ******Coords are 40.744316 and -73.998142; Accuracy 65 //But this indicates that the watchPosition success callback was eventually fired. Except that I didn't use the coords because the gotCoordsFlag had already been set to true. Maybe I need to tweak the timing of maximumAge? Nov 1 09:20:36 unknown GeoLocTest [5525] : [INFO] ****** STARTING LAT LON 40.744316, -73.998142 //This is the third activation of nearMe. Nov 1 09:20:36 unknown GeoLocTest [5525] : [INFO] ****** WATCH ID 19 Nov 1 09:20:37 unknown GeoLocTest [5525] : [INFO] ******Coords are 40.744301 and -73.998089; Accuracy 93.36 Nov 1 09:20:43 unknown GeoLocTest [5525] : [INFO] ******** TIMEOUT Lat is 40.744301 Nov 1 09:20:43 unknown GeoLocTest [5525] : [INFO] *** WATCH OFF VIA TIMEOUT *** USING PRIOR OR LOWER QUALITY COORDS and Accuracy is 93.36 Nov 1 09:20:43 unknown GeoLocTest [5525] : [INFO] ***** GOT COORDS Nov 1 09:20:43 unknown GeoLocTest [5525] : Loading stop Nov 1 09:20:46 unknown GeoLocTest [5525] : Loading stop Nov 1 09:20:46 unknown GeoLocTest [5525] : [INFO] ********** Flags: locSource GPS, mapView , gotCoords true Nov 1 09:20:56 unknown GeoLocTest [5525] : [INFO] ******Coords are 40.744327 and -73.998137; Accuracy 65 //Again, these lines are indications that the watchPosition success callback is being fired multiple times, which (AFAIK) is how the function is supposed to work now that your I implemented this.stop() fix. (Actually, it keeps getting fired - I need to tweak how I clear the watchID to minimize battery impact.) Nov 1 09:20:57 unknown GeoLocTest [5525] : [INFO] ******Coords are 40.744327 and -73.998137; Accuracy 65 Sorry for the lengthy code and console entries, but hopefully this is helpful. What do you think? Thanks! by: http://github.com/sromalewski (2011-11-01T15:11:21Z) Success! I've been testing my app in the field all morning, and watchPosition with repeated calls works just great - indoors, outdoors, with wifi, without wifi. I'll check my console log tonight when I'm back home, but for now I'm thrilled. Thanks @paulj ! by: http://github.com/sromalewski (2011-11-02T13:36:27Z) I've done some more testing, and checked my console log entries, and I think there's still a (or perhaps new) problem. Unless I haven't set up my code properly, I can't seem to clear the watchID after I've added @paulj 's "this.stop()" fix. Even though I've cleared the watchID and set it to null, every time I move my phone (even a few feet) the watchPosition success callback is called again and again. I even added a flag that's set to true after I get the coordinates, and watchPosition is still called: if (lmNS.gotcoordsFlag === false) { lmNS.watchID = navigator.geolocation.watchPosition(onGeoUpdateSuccess, onGeoUpdateError, geoOptions); } This doesn't seem to have any effect, watchPosition is called repeatedly even though lmNS.gotcoordsFlag has been set to true. And in my onGeoUpdateSuccess, the first line is the following: console.log('****** WATCH ID ' + lmNS.watchID); It returns: Nov 2 09:35:09 unknown GeoLocTest [6139] : [INFO] ****** WATCH ID null So the watchID is null and gotcoordsFlag is true, but watchPosition is still being called. I'm mystified. by: http://github.com/gregavola (2011-11-07T15:06:01Z) @sromalewski so it seems like there still is a bug with watchPosition? What about getPosition - does that appear to be fixed with this.stop();? by: http://github.com/sromalewski (2011-11-24T04:35:37Z) Not sure about getCurrentPosition. But I've implemented @paulj 's fix and it seems to work. Not ideal, but it's good enough for Apple – my app update with the fix was accepted for iTunes and is now in the AppStore (see http://spatialityapps.com/ ). It still seems buggy, but for now it's adequate. Btw, @mschulkind has a similar fix, but it didn't seem to provide anything different from paulj's fix – see https://github.com/phonegap/phonegap-iphone/issues/197#issuecomment-2741229 Odd that it's so problematic but isn't really being addressed head on. Several people have raised the issue recently on Google Groups: see http://groups.google.com/group/phonegap/browse_thread/thread/90e7eee2798b8bb2# and http://groups.google.com/group/phonegap/browse_thread/thread/1b8bd1e4716b0994# by: http://github.com/shazron (2011-11-24T20:46:56Z) Does this fix it? https://github.com/callback/callback-ios/pull/14 (already pulled into trunk) by: http://github.com/sromalewski (2011-11-28T05:36:31Z) Thanks @shazron. I'm reluctant to test this, though, because I'm not ready to upgrade to PG 1.2. Can I simply run the install with 1.2, add phonegap-1.2.0.js to my existing www folder, then build my app? I'm worried I'll run into problems, and then have to start from scratch by creating a new project and then manually importing all the plugins, etc.

          People

          • Assignee:
            Filip Maj
            Reporter:
            Shazron Abdullah
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development