Acknowledged
4 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
  • 4 months ago

    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.

    Yes, having to reinstall the app just to reset properties is really inconvenient. I initially planned to use properties to customize the app’s appearance for specific device types, but since I’m relying not only on the simulator but also on feedback from users with those devices, it becomes a hassle. With every small adjustment, I’d have to ask them to uninstall, reinstall, and reconfigure the app.

    Do properties that are no longer defined in a new version actually get deleted? If so, one possible workaround could be to add a version counter to the property name and increment it with each change.

    That said, I think I’ll switch to handling this in source code instead. I’ll define a base class with default constants and a derived class that’s actually used to access them. The derived class will reside in a separate source directory, and I can configure different directories per device in the jungle file. It’s about the same amount of effort as managing properties - since I didn’t like the default per-device resource folders in the root directory and had to define custom resource paths anyway for any non-default device configuration.

Comment
  • 4 months ago

    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.

    Yes, having to reinstall the app just to reset properties is really inconvenient. I initially planned to use properties to customize the app’s appearance for specific device types, but since I’m relying not only on the simulator but also on feedback from users with those devices, it becomes a hassle. With every small adjustment, I’d have to ask them to uninstall, reinstall, and reconfigure the app.

    Do properties that are no longer defined in a new version actually get deleted? If so, one possible workaround could be to add a version counter to the property name and increment it with each change.

    That said, I think I’ll switch to handling this in source code instead. I’ll define a base class with default constants and a derived class that’s actually used to access them. The derived class will reside in a separate source directory, and I can configure different directories per device in the jungle file. It’s about the same amount of effort as managing properties - since I didn’t like the default per-device resource folders in the root directory and had to define custom resource paths anyway for any non-default device configuration.

Children
No Data