[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

Former Member over 7 years ago

It is a bug, although no need to repost in the bug report forum. The issue has been fixed and should be available in the next release of GCM.

dbrobert over 7 years ago

I think that GCM might also be returning nested arrays of size one as a simple type. Or just unable to handle nested arrays period. For example, if my JSON contains something like this:

{"ident":"CYYC","taf":{"weather":["P6SM",["BKN060CB"],["TSRA"]]}}

which used to work fine, now seems to return{"ident":"CYYC","taf":{"weather":["P6SM","[BKN060CB]","[TSRA]"]}}.

Ugh. I know that bugs happen but I have to say, this is incredibly disappointing. And based on the frequency of GCM updates I'm expecting to have to wait a week or two before there is another GCM update. Which means now I have to find a workaround and then hope that the workaround isn't further broken when GCM is updated again.

Cheers (in a frowning manner),
Douglas

dbrobert over 7 years ago

I think that GCM might also be returning nested arrays of size one as a simple type. Or just unable to handle nested arrays period.

Actually, it looks like what really might be going on is that 'null' values within an array, which used to work, are being dropped. So, JSON like this:

["ABC",null,"123","XYZ",1]

is actually returned as:

["ABC","123","XYZ",1]

Resulting in an array that is one element shorter than expect and everything is offset. And while I could change this array to be a hash/dictionary, I have it as an ordered array to save on device memory.

Cheers,
Douglas

Former Member over 7 years ago

The nulls being dropped from arrays is also a bug that should be fixed with the next release of GCM for Android.

dbrobert over 7 years ago

The nulls being dropped is also a bug that should be fixed with the next release of GCM for android.

Do we know when that the next release of GCM will be? These two things seem like pretty big issues that require an immediate hot fix and release or a rollback. And how did this even happen? Surely I'm not the only one developing apps that retrieve JSON and utilize arrays with null values. Does the GCM team not need to coordinate with the Connect IQ team to ensure that everything works as expected, perhaps through unit testing and a specific test suite?

Is this limited only to Android or does this affect iOS also?

And finally, were these two bugs known prior to me posting this? And if so, why would that information not be posted so we could get ahead of this?

Cheers,
Douglas

mappicus over 7 years ago

Major problem for us too

We've also traced a sudden uptick in crash reports from our dwMap app to this (see https://forums.garmin.com/showthread.php?378486-Watchdog-timer-shortened-on-Forerunner-235 ), since these integers coming back as longs means they are objects, not Monkey C primitives, and creating an object count problem.

Former Member over 7 years ago

Null getting filtered out is a huge problem

My app is also relying on JSON data that contains an ordered array. If null values are filtered out it's impossible to know at what index to expect the correct data fields!
Since I'm getting the data from a 3rd party source I can't change the format of the JSON response.

This is a huge problem, please fix ASAP!
Any ideas for workaround strategies?

mappicus over 7 years ago

My app is also relying on JSON data that contains an ordered array. If null values are filtered out it's impossible to know at what index to expect the correct data fields!
Since I'm getting the data from a 3rd party source I can't change the format of the JSON response.

This is a huge problem, please fix ASAP!
Any ideas for workaround strategies?

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?

Coleman.Apps 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,
-Coleman

mappicus 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 Coleman. 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.