Issue migrating new settings?

I just released a new version of a widget today which has a new configuration option in the settings. The widget downloaded and worked fine until I went into Connect Mobile and changed the new setting. As soon as I did that, my widget would no longer work and I got the Connect IQ error symbol. Is this an issue with the way changes to the settings on the device are migrated or should I be doing something in my widget code to deal with this?

I checked the APPS/SETTINGS directory and the associated .SET file was unmodified since Friday (3 days ago) and the only way I was able to get the widget to work again was to uninstall and reinstall. And that in turn results in the settings for the app to be reset. That's fine for me but it will be a pretty poor experience for regular users.

For reference, the error in the CIQ_LOG.TXT was:

ERROR: Unhandled Exception

DETAILS: Failed invoking <symbol>

That seems to point to a coding error, however as noted above, when I uninstalled and then re-installed the widget functioned properly.

Has anyone else experienced this? Or have thoughts on what I might do to avoid this?

Cheers,
Douglas

dbrobert over 8 years ago

Further to my issue, it seems this isn't a problem with settings migration but a problem with changing settings via Connect Mobile. As soon as I change a setting using Connect Mobile the widget displays the Connect IQ error. But if I connect my D2 Bravo to the cradle and change the settings using Garmin Express the widget works perfectly again.

Is this a known issue? Does this relate to the past problems Connect Mobile has had (such as this thread that mentions that Connect Mobile can return the wrong type -- https://forums.garmin.com/showthread.php?341818-Issue-debugging-settings )?

Cheers,
Douglas

Former Member over 8 years ago

Must be that YYC air (I will send you some fresh stuff from here in YEG :p) .. no actually I had similar issues and gave up. Mine was a watch face.

I found that everything worked fine using the object store exclusively but once I tried to implement a setting in Garmin Connect, it was like it got mixed up and it started giving me an error identical to what you posted. It was like it was returning null from a object store item (after adding a setting) that never happened before .. and I could not check for null as it just crashed no matter what I tried.

I too would be very interested in the outcome of this one. I am using a Vivoactive HR btw.

Btw .. it looked like it was returning a valid value from Garmin Connect. In my case, it was a simple number. Doesn't get much simpler than that. But I could not get it to work. Hopefully one of the experts will post a step by step on adding a setting cause it should not be this hard.

jim_m_58 over 8 years ago

dbrobert-
Without seeing your code, my guess would be that you're seeing what's discussed in the thread you linked - the "type" problem specifically. As it works with GE but not with GCM (Android or iOS BTW?), I suspect it's something like you're getting a float where you expect a number, and maybe taking a path in your code resulting in the error you see in ciq_log.txt

dbrobert over 8 years ago

The day I take advice from someone living in the "City of Champions" is the day I stop breathing air. :p Ha! Just kidding, of course. Though, I continue to raise my eyebrows over the closing of the City Centre airport. But I digress... :)

Glad it's not just me running into this issue. The odd thing is that changing the configuration using the mobile app for the past two releases but suddenly it doesn't work. And short of releasing a bunch of versions to continually try ways to work around this, I don't know what to do.

Cheers,
Douglas

dbrobert over 8 years ago

dbrobert-
Without seeing your code, my guess would be that you're seeing what's discussed in the thread you linked - the "type" problem specifically. As it works with GE but not with GCM (Android or iOS BTW?), I suspect it's something like you're getting a float where you expect a number, and maybe taking a path in your code resulting in the error you see in ciq_log.txt

Thanks.

I use Android for GCM and don't have access to iOS to confirm if it's an issue there also. However, I'm now seeing a *tonne* of watch face descriptions that say something like "don't use GCM to change the configuration" so it seems like this might be a widespread issue. Has anyone heard any response from Garmin on this?

I think I'll try wrapping some code around the config stuff as suggested in that thread and see what I come up with.

Cheers,
Douglas

Former Member over 8 years ago

dbrobert-
Without seeing your code, my guess would be that you're seeing what's discussed in the thread you linked - the "type" problem specifically. As it works with GE but not with GCM (Android or iOS BTW?), I suspect it's something like you're getting a float where you expect a number, and maybe taking a path in your code resulting in the error you see in ciq_log.txt

Mine as you know, was not a type issue. It returned a number as expected. But there was a new GCM version update .. so maybe someday soon I will try it again.

I think I will just create a simple stripped down version .. just for testing until I can get it to work 100%.

jim_m_58 over 8 years ago

However, I'm now seeing a *tonne* of watch face descriptions that say something like "don't use GCM to change the configuration" so it seems like this might be a widespread issue.
Douglas

I think what you're seeing are things added in the descriptions quite a while back when people were just figuring out app settings, and the whole "type checking" part wasn't widely known. I do know of one weird one when using the "date" type for settings and GCM/A, but that's it

From my own experience, I've not had a single reported problem with app settings from GE, GCM/A or GCM/iOS, probably since last year. The key is the type checking code as far as I can see.

Here's the code I use for Numbers - if the key data is bad, return a default.. Based on what I'm doing, the calling code may also do some range checking, etc. With GCM/A you can get in a state where a "version 1" of something is on the watch while the "version 2" app settings are used by GCM/A, and for a given Number, "version 1" may only support a range of 1 to 5, while "version 2" allows for 1 to 6, for example. If the "version 1" is handed a value of 6, you want to make sure "version 1" can handle it.

function readKeyInt(myApp,key,thisDefault) {

        var value = myApp.getProperty(key);

        if(value==null || !(value instanceof Number)) {

		if(value!=null) {

			value=value.toNumber();

		} else {

        		value=thisDefault;

        	}

        }

        return value;    

    }

dbrobert over 8 years ago

As per Jim's suggestion, I've wrapped the property methods in a new class that checks for type and returning a default as specified. I released a new version today and haven't yet experienced any issues. But I also didn't add or change any of the settings properties so I can't confirm that this is/was the issue. I'll try and report back when a future release has a settings change.

Cheers,
Douglas

jim_m_58 over 8 years ago

Glad I could help!

If you weren't doing type checking for the setting before, I have no doubt this will make a difference! (BTW, I have a similar check for Booleans in settings just in case!)