Watchdog timer shortened on Forerunner 235?

It's got a 1.4.1 VM, and I don't think that's changed in a while and is the same as on the 230 (the WD is kind of a VM thing). Are you seeing it as a problem with the WD in ciq_log.txt?

I can say pretty confidently that they did not reduce the watchdog count in a recent update of the 235, but the count on that device (and all 1.x wearables IIRC) is 33% less than the count on our 2.x wearables because it runs on slower hardware. If something in a 235 release is causing an error in one of your applications, it is more likely that the results of an API call were accidentally changed to something your application is not expecting. You will definitely want to try to get your hands on a CIQ_LOG.txt from a device experiencing the issue.

adidas DRIVE

Thanks Jim and Brian.

I am getting CIQ_LOG.txt in from users now, and they are actually showing it's the 'Too Many Objects Error' exception and not the watchdog. I've dealt with this before in our other app, but never seen it in dwMap before.

Is there a way to count and log the number of objects being used so I can review variable types and move over to primitives rather than objects in a systematic way where possible?

Is there a way to count and log the number of objects being used so I can review variable types and move over to primitives rather than objects in a systematic way where possible?

if you haven't moved to 2.3.1, one of the new things there is in the "view memory" screen in the sim, you see the current object count, max objects and peak objects.

With the debugger, you could set a breakpoint in the suspect code to see the info there.

if you haven't moved to 2.3.1, one of the new things there is in the "view memory" screen in the sim, you see the current object count, max objects and peak objects.
With the debugger, you could set a breakpoint in the suspect code to see the info there.

That's perfect, thanks for the tip!

What a rabbit hole this has been!

FYI, after much tracing, logging, and tearing-out-of-hair, this appears like it might be because of this:
https://forums.garmin.com/showthread.php?378341-New-GCM-is-returning-JSON-numbers-as-Long

We send our map data encoded into a compact integer representation, and since integers are the Number primitive, they are not objects. But if they are actually coming in as type Long then they are objects, and lots of them, and hence we unexpectedly hit the object count ceiling.

Hey all,

Thanks for all the work here. In the past the workaround on this has usually been pretty easy because most developers weren't using numbers in this way. A simple type check was all most needed. With this type of implementation it's clear that this is becoming a problem as developers are beginning to use this in more robust ways. I've got a new ticket created for us to tackle here. Thank you again.

-Coleman

Hey all,

Thanks for all the work here. In the past the workaround on this has usually been pretty easy because most developers weren't using numbers in this way. A simple type check was all most needed. With this type of implementation it's clear that this is becoming a problem as developers are beginning to use this in more robust ways. I've got a new ticket created for us to tackle here. Thank you again.

-Coleman

Thanks Coleman. In this case I don't think a workaround is even possible as the collection returned for the JSON returned by the data call will already have a large array of Long objects, and crash, before we can do anything about it?

I totally agree. It after digging a little deeper. It actually looks like a bug fix may be in place on the next release. I've kept my ticket open to try and put a better sense of urgency on it. You are correct that there isn't a viable workaround at the moment since the array of Long objects are causing an object limit crash. Thank you again.

-Coleman