Acknowledged
2 months ago
CIQQA-3217

Simulator does not apply updated property values without "Reset All App Data"

In the Connect IQ simulator (SDK 8.1.1), changes to <property> values are not reflected unless Reset All App Data is performed.

Steps to Reproduce:

  1. Define properties, for example::

    <resources>
    <properties>
        <property id="menuTitleBackgroundColor" type="number">0x212021</property>
        <property id="menuItemLeftPaddingFactor" type="float">0.03</property>
    </properties>
</resources>

  2. Launch the app in the simulator and close the simulator again.

  3. Modify one of the <property> values in the XML file.

  4. Relaunch the app in the simulator (without resetting app data).

Expected Result:
The updated property values should be reflected when the app is reloaded.

Actual Result:
The simulator continues to use the old property values until Reset All App Data is performed.

Additional Notes:

  • If different values are specified for individual devices, switching between devices does not trigger a property refresh. The simulator continues using the values from the first device launched after the last reset.

  • This issue makes it difficult to test dynamic UI changes based on property updates.

SDK Version: 8.1.1

the-ninth
Parents
  • 2 months ago

    Yes, understand how this makes sense considering that the app also can write properties.I guess if the simulator would clear the properties with every updated version/different device, it could be equally annoying for developers testing apps that set values.

    Again, to be clear, I am referring to both the behaviour in the sim and on a real device (after an app update).

    Cool would be if running an updated version/different device would update the value ONLY IF it is still at its default value.

    Ah, but what if the user or app toggles a boolean property/setting twice (for example), so that the property is changed from the default value, then changed back to the default? If the app is now updating so that the default property is the opposite of what it used to be, should the property value change?

    I understand that the current behaviour is not ideal for all use cases (and the real behaviour on the device has tripped up devs in the forums before).

    But if you consider the alternatives, I think Garmin's motivation for doing it this way becomes clearer.

    I do recognize that you have a special use case which involves properties which differ between devices, which is only relevant for testing in the sim and not for deploying apps on real devices.

    As a side note, I don't think the system is perfect. Years ago there was a quirk where an app could receive null for all settings if the user was able to submit a setting that contained an error (like a filling in a numerical field with a non-numerical string). In this case, the app would ideally use default values for all the settings, but that would also mean that the default values would have to be duplicated in the .mc source files *and* the resources.

    To better handle this issue, I thought it would've been nice if the app had access to the default settings values at runtime. This would also allow to easily provide an on-device function to reset all settings to default. (Come to think of it, it would be nice to have this in the Connect IQ store app itself.) Currently the only way for the user to do this is to uninstall the app, then reinstall it.

Comment
  • 2 months ago

    Yes, understand how this makes sense considering that the app also can write properties.I guess if the simulator would clear the properties with every updated version/different device, it could be equally annoying for developers testing apps that set values.

    Again, to be clear, I am referring to both the behaviour in the sim and on a real device (after an app update).

    Cool would be if running an updated version/different device would update the value ONLY IF it is still at its default value.

    Ah, but what if the user or app toggles a boolean property/setting twice (for example), so that the property is changed from the default value, then changed back to the default? If the app is now updating so that the default property is the opposite of what it used to be, should the property value change?

    I understand that the current behaviour is not ideal for all use cases (and the real behaviour on the device has tripped up devs in the forums before).

    But if you consider the alternatives, I think Garmin's motivation for doing it this way becomes clearer.

    I do recognize that you have a special use case which involves properties which differ between devices, which is only relevant for testing in the sim and not for deploying apps on real devices.

    As a side note, I don't think the system is perfect. Years ago there was a quirk where an app could receive null for all settings if the user was able to submit a setting that contained an error (like a filling in a numerical field with a non-numerical string). In this case, the app would ideally use default values for all the settings, but that would also mean that the default values would have to be duplicated in the .mc source files *and* the resources.

    To better handle this issue, I thought it would've been nice if the app had access to the default settings values at runtime. This would also allow to easily provide an on-device function to reset all settings to default. (Come to think of it, it would be nice to have this in the Connect IQ store app itself.) Currently the only way for the user to do this is to uninstall the app, then reinstall it.

Children
No Data