Geolocation in Simulator uses String Values Instead of Numbers

[Richardsonke]

There's an inconsistency in the geolocation data returned by the Icenium simulator compared to the geolocation data on a device.

In the simulator, run this code snippet:

var testPos = null;
navigator.geolocation.getCurrentPosition(function(pos){testPos = pos}, function(error) {}, { enableHighAccuracy: true });

Then

check the value of testPos.coords.  Here is a sample:

Position {coords: Coordinates, timestamp: Fri Aug 30 2013 13:06:28 GMT-0400 (Eastern Daylight Time)}

coords: Coordinates
accuracy: "100"
altitude: "100"
altitudeAccuracy: "80"
heading: "0"
latitude: "40.6891236071156"
longitude: "-74.0444827079773"
speed: "0"
__proto__: Object
timestamp: Fri Aug 30 2013 13:06:28 GMT-0400 (Eastern Daylight Time)
__proto__: Object

However, if you run this same command in a browser or on a mobile device, you get something like this:

Geoposition {timestamp: 1377881680678, coords: Coordinates}
coords: Coordinates
accuracy: 40
altitude: null
altitudeAccuracy: null
heading: null
latitude: 40.6891236071156
longitude: -74.0444827079773
speed: null
__proto__: Coordinates
timestamp: 1377881680678
__proto__: Geoposition

Notice that all of the values for coords properties are numbers, rather than strings.  According to the W3C documentation, the properties of the Coordinates interface are all supposed to be doubles.  If the values are not checked to be of type "number" before using them with the Google Maps API, it will throw errors.  For example, calling _userCircle.setRadius(position.coords.accuracy); on the simulator results in the error "Error in error callback: Geolocation1260449180 = Error: Invalid value for property <radius>: 100"

As a side note, according to the W3C documentation, the Position.timestamp property is supposed to be of type DOMTimeStamp, not Date.  This does not seem to be 100% accepted by everyone because on iOS it is a Date type, but on Android and Chrome, it is a DOMTimeStamp.

[Richardsonke]

As a follow up, I found the bug report in WebKit back in 11/2010 that changed DOMTimeStamp from using a Date to a Long: https://bugs.webkit.org/show_bug.cgi?id=49963.  For some reason, iOS still hasn't implemented this change, even in iOS 7.  

[Steve]

Hi Keith,

Thanks for bringing this to our attention, I've logged this into our bug tracking system and it would be fixed for subsequent version of Icenium. For the time being, should you need to test your app in the Simulator, please use Mist instead, as the problem is only in the Graphite simulator.

Your Telerik points have been updated as a token of gratitude for reporting this issue.

Regards,
Steve
Telerik

Looking for tips & tricks directly from the Icenium team? Check out our blog!
Share feedback and vote for features on our Feedback Portal.