• Replies 3 replies
  • Subscribers 19 subscribers
  • Views 1451 views
  • Users 0 members are here
Options
Related

[SOLVED] Changing properties from Connect IQ immediately crash the app - even though I don't use getValue() or setValue() anywhere!

Cuiv

So I have an app where most of my settings are done directly on the watch. This works great.

I wanted to test having a couple of settings done from the phone, so I added a settings.xml file with:

<settings>

  <setting propertyKey="@Properties.userLivetrackUserName" title="@Strings.titleLivetrackUserName">
    <settingConfig type="alphaNumeric" errorMessage="@Strings.titleInputError" />
  </setting>
</settings>
I have the property in the properties.xml file:
<property id="userLivetrackUserName" type="string">username</property>
And the strings.xml file have the correct strings:
<string id="titleLivetrackUserName">Livetrack Username</string>
<string id="titleInputError">Wrong input</string>
Now here's the kicker: for now I'm not using those properties anywhere in the app. At all. No getValue(), no setValue(), nothing. I just wanted to test the look and feel from the phone.
In the simulator, no problem at all.
On the phone after publishing as a Beta app, I can get the Settings screen in Connect IQ app, I can see the default value, I can edit it, and I can save it. I get a save successful message.
However, on the watch (Fenix 7X 7.35) the app immediately crashes when the phone saves (stack gives "Unhandled Exception" only). And it then crashes upon startup. The only way to run the app again is to uninstall and reinstall the app. It's as if something got corrupted in the app.
Any idea what could be happening??

  • OK I have some elements of an answer.

    I have some other properties that are amended directly from pickers within the watch app. And upon settings change, I load the property values that are set via pickers within the watch app to variables within a MySettings class instance (sometimes with things like units translations involved), so I can refer to the MySettings variables in the rest of the app, rather than going back to the properties every time. So I do use getValue(), but only for the properties that are not exposed to Connect IQ app via Settings.xml (that have always worked up to now).

    This works fine. However, I think that when exposing one new field to Connect IQ settings via Settings.xml, and when saving from Connect IQ, Connect IQ messes with the values of the other properties (the ones not exposed via Settings.xml)! And somehow breaks them (probably tries to copy them as is, but somehow fails). This only happens on the watch+phone, not in the simulator.

    The reason I can say this is that I have one setting (set within the watch app via picker) which is the background color. There is one instance where I managed to save my additional field (that doesn't do anything yet, and is never read in the watch app) within the ConnectIQ app without crashing the phone app, but once done the background color of the app changed!

    It actually makes me think that Garmin calls the onSettingsChanged() before it has fully finished writing the amended properties?

    That would be extremely unfortunate...

  • Yeeeah I think I can confirm corruption of properties that are not set within Garmin IQ app is happening. I used onSettingsChange() to separate my Connect IQ app set property and the rest of the properties:

    1. If the connect IQ app set property "userLivetrackUserName" has changed, then do nothing

    2. else (e.g. one of the other properties has been changed directly within the watch app, via picker), load my properties into variables as usual.

    This makes saving the property from the Connect IQ app doesn't crash the app anymore. However, once that happens, my other properties are corrupted and can't be read to my variables anymore (I suspect type issues). So I guess I need to add a type check on all my other properties. I'll try that...

  • Aaand I think fixed it. So here's what was happening:

    - For my existing properties, the way I worked was that type was guaranteed, nullness was not. So I was just checking for nullness, not type.

    - HOWEVER when adding even a single property that can be changed via ConnectIQ and using ConnectIQ to amend it, then this affects all the other properties, and in particular their types (Number properties have then a bad habit of returning Floats). So you then *must* implement the type check detailed in this FAQ for all properties, including the ones not set via ConnectIQ: https://forums.garmin.com/developer/connect-iq/w/wiki/4/new-developer-faq#settings-crash