[Fixed] - New GCM is returning JSON numbers as Long

I don't know if this is a "bug" per se so I'm posting this here, plus I thought it best to allow for maximum exposure to all. I updated to the latest version of GCM (3.19) on my Android device and discovered that my METAR/TAF widget no longer works and crashes with the IQ! page, despite no code changes. This also explains a recent review I just noticed stating the same.

Having now been debugging for the past few hours, I've discovered that the latest version of GCM (3.19) on Android returns numbers within JSON retrieved from the Internet as a type Long. This would be fine if except that if you are using any of those JSON values as array indexes you will receive the following error:

UnexpectedTypeException: Expected Number, given Long

Although this looks like the issue with retrieving settings values, as recently brought up again in this thread, the error I'm seeing is, in this case, a result of arrays not accepting Long values for an index. And the reason I'm using a Long is because I'm using a value from JSON data I retrieved from an API endpoint.

I don't have an iOS device to test with but this might also affect iOS too. Though if this affects your app, you'll want to handle it regardless unless you can guarantee you don't have any Android users.

Garmin folks: if this should be considered a bug (albeit outside of the CIQ team), let me know and I'll repost properly.

Cheers,
Douglas
  • I agree--there must be a lot of apps with issues right now, some subtly buried.
    Although the data is coming from a third party could you filter it through a simple web service that replaces nulls with zeros or some defined value that the app could be changed to recognized as being a placeholder for null?


    That's exactly what I did; I changed any [FONT=Courier New]null[/FONT] value to a string containing the word 'null' as such: [FONT=Courier New]"null"[/FONT]. It's a serious hack but it has at least solved the ordered array issue I was running into.

    Doesn't help with the object count issue though so I'm still getting reports of crashes on the older, less powerful devices.

    Cheers,
    Douglas
  • Former Member
    Former Member over 7 years ago
    Please can you check that the same changes are not planned for the iOS version of GCM? It'll be a fresh nightmare if there's an iOS release with this flaw poised to ship.

    This should not be a problem on iOS and I can verify that the changes that caused the bug to begin with only ever affected Android.
  • Former Member
    Former Member over 7 years ago
    I've noted in the related forum thread here that there is a fix in place that should be out with the next release of GCM. I'm continuing to try to make sure that these items stay a top priority for our developers.


    Thanks! Do you have an estimate on when the updated GCM will be available?
  • Hello All,

    We have a fix for the JSON returning longs issue. It should be live on Google Play within the next few hours. Please let us know if you experience any other issues after the update!

    Thanks,
    -Coleman
  • Hello All,

    We have a fix for the JSON returning longs issue. It should be live on Google Play within the next few hours. Please let us know if you experience any other issues after the update!

    Thanks,
    -Coleman


    My Android users are reporting that everything is looking good now after this new release of Garmin Connect Mobile for Android (V3.19.1). Thanks!
  • So glad to hear it! I'm going to edit this thread description so others know this is fixed.

    -Coleman
  • Does anyone know what the max length of the json response is and whether this is the same in iOS and Android?
    I currently am hitting a 400 error with my makeWebRequest when the phone is Android, but I never get the issue when it is iPhone.

    I believe I have the latest version of GCM Android as I installed a fresh copy of it it last night on my wife's phone to investigate the 400 error.
    The url is exactly the same as it is when sending to an iPhone, so I assume it has to be a difference in how GCM on Android handles the response compared to iPhone.

    The issue happens on the newer type of devices: first reported by a Chronos user, but also reproduced by me on 935 and f5s. So I don't think it is an object count issue and it is giving 400 error, not crashing, so is different from the original issue posted here.

    To me 400 means a bad request. So could it be that the default options / headers for the request are not handled correctly on Android?

    I have the code as follows:

    var options = {

    :methods => Comm.HTTP_REQUEST_METHOD_GET,

    :responseType => Comm.HTTP_RESPONSE_CONTENT_TYPE_JSON

    };

    Comm.makeWebRequest(url, null, options, method(:onReceive));



    Another thing: My url contains all the querystring parameters. I am not using the params dictionary for this purpose. Could this also be an issue?