Show field app settings

To expand on this answer, you have to implement your own view (such as a Menu2) which handles on-device settings - you are responsible for writing all the code for the UI and persisting settings. This view should be returned by getSettingsView(), which you would override in your app class. So unfortunately, you cannot somehow automatically "publish" your existing settings (defined in resource xml files) to an on-device settings screen, you have to manually write all the code yourself.

onSettingsChanged() is not related to on-device settings - it is called when "off device settings" are changed via the Connect IQ phone app. "Off device settings" are the original kind of settings for CIQ apps, where you define settings in resource XML files, and they're presented in the Connect IQ phone app (and Garmin Express).

For an example of the usage of getSettingsView(), look at the Analog SDK sample. In VS Code, open the command palette (CTRL-SHIFT-P / CMD-SHIFT-P) and select "Monkey C: Open Sample Folder".

Hmn...Maybe I should consider to keep it in CIQ App.
is there a way of accessing settings on the device when doing test (on the device - not simulator) without the need for CIQ ?

If it's settings.xml then you'll need to upload it to the store (at least as a beta app). If it's on-device settings, then it's enough to side-load

There is a way - some kind of middle way - to set properties on the device without using CIQ App.
I‘ve done it using getProperty() and setProperty():

unfortunately I‘m not able to upload a screenshot… will try later

If I understand how that works, it's basically a special test build, with some code you comment out and set tthe properties to what you want them to be, right? While that certainly can work, but it has it's problems. You should not forget to comment the lines out before you export the project :) and you'll need to make a new build and side load for each settings variation. While this can work when you only want to test a few variations, it might not fit every case.

Even though the store (and uploading to it, and getting an already approved beta app's new version "published") has it's own problems, I still use this in case an app uses settings, especially when I want to test the settings. There are some things you can't test without it. For example I usually make my apps responsive to settings in real time. So if the app/datafield is running and you change the settings, you see the effect immediately. There can be tricky things in this but it's a good user experience (though I'm not sure many users use it)

Nearly all options I offer in „Quick Settings“ can be done during an activity without getting into troubles. 
Some options are greyed out after starting the activity - like chosing the optional sport.

And all the Quick Settings are of course available in CIQ App settings with better description…

mcinner1 said:

There is a way - some kind of middle way - to set properties on the device without using CIQ App.
I‘ve done it using getProperty() and setProperty():

unfortunately I‘m not able to upload a screenshot… will try later

It seems to me that you implemented your own settings UI in a full-screen data field without using "on-device settings", but instead taking advantage of touch support on the Edge to bring up the settings UI more quickly / easily.

My only comments are:

- not all CIQ watches support touch for data fields, and even those that do cannot rely on touch support, as the user can disable touch for 5-button watches and still use 99% of the watch's functionality (which means that a user can record a whole activity without ever enabling touch)

- if I'm understanding what you did correctly, it really isn't less work on the coding side compared to on-device settings. You still have to write the code for the UI and persisting settings, it's just slightly easier for the user to access settings (although you haven't really shown how settings are accessed - I assume there's some button on your full-screen data page.)

flocsy🤠 said:

If I understand how that works, it's basically a special test build, with some code you comment out and set tthe properties to what you want them to be, right?

I could be wrong but I don't think that's what it is at all.

I think it's just a settings UI for a full-screen data field that's triggered via touch interaction, as opposed to standard "on-device settings". It's no less work for the dev (in fact it might be even more work than usual), but it might be more convenient for the end user.

As I said above, I don't think it's appropriate for watches at all, as it relies on touch. (Unless you only target "touch-first" watches where most of the basic functionality requires touch.)

It's either what I said above, or it's actually a device app which just implements its own settings UI.

Ofc this is no different in principle than on-device settings (which is why on-device settings don't exist for device apps).