Geolocation in Simulator uses String Values Instead of Numbers

3 posts, 0 answers
  1. Richardsonke
    Richardsonke avatar
    93 posts
    Member since:
    Jul 2007

    Posted 30 Aug 2013 Link to this post

    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.
  2. Richardsonke
    Richardsonke avatar
    93 posts
    Member since:
    Jul 2007

    Posted 30 Aug 2013 Link to this post

    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.  

  3. Steve
    Admin
    Steve avatar
    10941 posts

    Posted 03 Sep 2013 Link to this post

    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.
Back to Top