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

You could use JSON resources instead of properties for that kind of thing, assuming you don't need to support ancient CIQ 1 devices which lack support. (JSON resources were introduced in CIQ 2.3)

Thanks for the suggestion - I wasn't aware of JSON resources. That said, I prefer the approach using separate source code directories. This way, I can take full advantage of all available types, such as FontDefinition or ColorType, when defining properties. It also allows the compiler to enforce correctness, whereas JSON resources may require additional effort to ensure everything is properly defined.

I've defined a DefaultConstants class that provides default values for all constants. Building on that, I created a Constants class that serves as the main access point for these values. There are multiple source directories, each containing its own implementation of Constants. The base implementation is essentially empty - it inherits all defaults from DefaultConstants and is used for most devices. For specific devices, I have separate source directories with Constants implementations that override certain values as needed.

You could use JSON resources instead of properties for that kind of thing, assuming you don't need to support ancient CIQ 1 devices which lack support. (JSON resources were introduced in CIQ 2.3)

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.

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.

hi, you have, to avoid reset data, in VSC: MonkeyC: Clean Project, to delete output folder and so reflet the change made in settings etc.

I tried it, but it did not help. I think once the app has been loaded, the properties are stored in the simulator.

For my particular use case I'd have to clear only the properties that are not settings. I do not want to have to redo al the settings everytime I switch to a different device. For example there could be a window showing the properties similar to the settings, and for each of them a button to reset them.

But now back to reality, there are more pressing issues for the CIQ team I guess.