incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shazron Abdullah (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CB-55) Geolocation.prototype.watchPosition uses timeout option in wrong way
Date Mon, 28 Nov 2011 22:35:40 GMT

    [ https://issues.apache.org/jira/browse/CB-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158873#comment-13158873
] 

Shazron Abdullah commented on CB-55:
------------------------------------

by: https://github.com/all4ip

Yes, I use the merged version. The major change is the line "Retrieve location immediately
and schedule next retrieval afterwards".

But that's not what I ment.

I was reading now much more of the documentation (http://dev.w3.org/geo/api/spec-source.html)
and was close to admit that I am wrong, but now again, I don't think so.

Here is my interpretation how the w3c specification is ment:

getCurrentPosition() has its timeout which will be triggered only if no position is available
until then and will return a position earlier otherwise.

watchPosition() will continuously retrieve positions and call the success callback on a not
configurable high frequency while "new position differs significantly from the previous position".
Only if no position is available for as many seconds as defined by timeout, then the timout
error should occur.

So the params.timeout should not be used in "setInterval(intervalFunction, params.timeout)".
There should be used a value like 100 or 500 or 1000 ms.

The w3c doc continues:

"In step 5.2.2 of the watch process, the successCallback is only invoked when a new position
is obtained and this position differs signifficantly from the previously reported position.
The definition of what consitutes a significant difference is left to the implementation.
Furthermore, in steps 5.2.2 and 5.2.3, implementations may impose limitations on the frequency
of callbacks so as to avoid inadvertently consuming a disproportionate amount of resources."

So I would for simplicy reasons return all values and omit calculation of position differences,
as it is done now in the currenty implementation.

But the interval frequency should NOT be set by the params.timeout, it has to be a static
implementation.

When I was close to admit I am wrong I thought, I have to use params.timeout with 1000 and
would be fine with it, because I want updates every second. But I also want to use a timeout
of 30000, to allow the app to start up GPS and acquire the first position and so on, when
the app starts the first time and allow up to 30 seconds of not receiving a position if the
app travels i.e. through a tunnel. This should be possible with the w3c specification, but
is not with the current PhoneGap implementation. So I still think the timout options is used
at a wrong place.

The conclusion:

1. setInterval(intervalFunction, params.timeout) should be changed to setInterval(intervalFunction,
500)
2. a filter should be implemented to return only positions, which "position differs signifficantly
from the previously reported position" (this may be done later)
                
> Geolocation.prototype.watchPosition uses timeout option in wrong way
> --------------------------------------------------------------------
>
>                 Key: CB-55
>                 URL: https://issues.apache.org/jira/browse/CB-55
>             Project: Apache Callback
>          Issue Type: Bug
>          Components: iOS
>            Reporter: Shazron Abdullah
>
> reported at: https://github.com/phonegap/phonegap-iphone/issues/305
> by: https://github.com/all4ip
> I have following scenario:
> I want aprox. every second a position update. I do not want cached positions. I am willing
to wait up to 30 seconds for the first valid position.
> So my params would be:
> var options = { timeout: 30000, maximumAge: 0, enableHighAccuracy: true };
> This is identical to w3c definition.
> But the timout value is also used for the internal endless loop of watchPosition. So
I can either have updates every second and can wait up to 1 second for valid position or wait
up to 30 seconds for valid position and get updates only every 30 seconds, too!
> The timout option should be used like the doc says:
> "The maximum length of time (msec) that is allowed to pass from the call to geolocation.getCurrentPosition
or geolocation.watchPosition until the corresponding geolocationSuccess callback is invoked."
> This happens correctly, when the params are passed to getCurrentPosition().
> But the continuous update in watchPosition uses the same value for the timer, too:
> setInterval(intervalFunction, params.timeout);
> The interval should be a static value i.e. 1000 ms or 500 ms or a variable frequency.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message