Settings from Garmin Mobile and Garmin Express (PC) are different!

Former Member
Former Member
Hey guys, please help to understand how to fix an issue with failing watch face after settings update through Garmin Mobile (Android). When users do settings update with it, watch face crashes with:
ERROR: Unhandled Exception
DETAILS: Failed invoking symbol

Everything is fine if settings are set through Garmin Express (PC).
I've tested both cases, and setting files (.SET) are different. Can anybody tell why and what I can do with that?

Settings files attached.


P.S. Does anybody know how to test settings on actual device with dev app? I can't specify settings for apps I upload manually. Is it supposed to be like that or I'm doing something wrong?
  • No way to test with a mobile and a sideload right now (you can copy .set files from the simulator to the watch, but that's it). Some people have created a "Beta app" in the app store that they use for testing, with warnings that's it's not ready for release.

    But, you may be able to fix this without that. One of the oddities with app settings, is that there are times, that something like a number is placed in the property as a string.

    so instead of seeing the number 6, it has "6", for example.

    What I do is check the property for null and for "instanceof"

    for example:

    newval=app.getProperty(k_rtype);

    if(newval!=null && newval instanceof Number) {

    to catch this. You can also check for "instanceof String" if it's not a number, and then do something like

    newval=newval.toNumber();
  • Jim is correct, it is a known issue that Android saves numbers as strings
    So you can do toNumber() to guarantee correct type
  • Isn't there also an issue on Garmin Connect Mobile for Android where if you change more than one setting, all are set back to null or something like that?
  • Travis, I don't think I've ever seen that, and I use Android all the time. Seems there's a case where if you mark something as "required', you have to enter it each time though... (it requires you to enter it, even if it already has a value). I'm not sure that's a bug or by design, because it could be "required to be entered" vs "required to have a value".