Okay to have different CIQ settings for different devices?

sure you can have other settings on other devices, no problem. Look into jungles in the dev doc

simple example:
fenix3.resourcePath = $(fenix3.resourcePath);_jungle/fenix3_settings.xml

fenix5.resourcePath = $(fenix5.resourcePath);_jungle/fenix5_settings.xml


Thanks peterdedecker Actually, the app in question already has a ton of conditional resources and code (although it's currently done in the old, non-jungle way), and I aware of how to do it with jungles, too.

My real question is why other devs aren't doing it and is there something I'm missing? There's one popular app (over 100k downloads) which has a feature unavailable on CIQ1, and the label for that setting says "Only for [new] devices X, Y, Z". There is another setting only for older devices as well, with a similar label, except it lists older devices. It seems like it would be trivial (and less confusing) to simply omit those settings for devices which don't apply.

I've seen this kind of thing in more than one app, so I was wondering if these devs have encountered some problem I am not aware of. I only have a 935 to test with, so if 230 users (for example) are seeing these settings in the app, I won't know unless they tell me. Or if it causes some kind of problem somehow (although this is doubtful to me).

This is important to me because app settings take up memory at run-time, and I cannot increase my RAM footprint by even 50 bytes for older devices. (This goes back to how I wish it was possible to "unload" app settings and properties once I'm done with them, since I only need them at init.)

Everything I know about Connect IQ (not much) tells me that this should be okay, but I don't understand why other devs don't do it.

Ease of Maintenance is likely a big part of why only one version of settings is used. In one of my apps, as a rough guess, I'd need 10 different versions of settings. CIQ version, as well as things like Sensor History (and which of the 4 are available), wearable vs non-wearable, etc.

And when you have 10 versions and want to add/remove a setting, that's a bunch of code to change and test.

jim_m_58 okay, fair enough. Thanks! Just wanted to make sure there isn't some hidden constraint I didn't know about.

I can assure you that it works. I'm doing it in multiple apps (Data Lover, All In One, Peter's (Race) Pacer, etc...) and without wasting memory on unnecessary settings I wouldn't be able to get them under the memory limit.

peterdedecker Thank you very much, that's exactly what I was looking for. Appreciate it!

peterdedecker I guess the other thing that threw me off is the fact that the App Settings Editor has a checkbox for rebuilding, but no drop-down for device selection, which suggests that the app settings definition is independent of the device. Of course, it will come from the last build, which could be the default build or a device-specific build. I sort of wish the default build always had a device associated with it. Having a default build with no associated device seems to open up a whole can of worms if you do a lot of device-specific stuff, like excluded annotations or device-specific app settings.

So to test app settings for different devices, I have to counter-intuitively:
1) Run the app (which puts the build for that specific device in the bin/ directory)
2) Then open the app settings wizard

Ironically, if I use the "build for device wizard", it won't work, because that doesn't update the local project bin/ directory. A normal build or auto-build might not work, because normal builds are often for "no device". (Although it seems that a build after running for a specific device might work)

I just think the workflow is very counter-intuitive.

And in general, a "no-device build" doesn't represent a form that your app can actually take. Nobody's taking the no-device build and deploying it anywhere, nor is it ever going to run on anything.

(It just so happens in many cases, the binaries/resources for the no-device build are the same or similar enough to the output for a specific device build)

TL;DR -- the default build needs to always have a device, somehow, IMO.

hi, very instructive thread,

I may have a question.

So far I created a project where default properties/settings are for CIQ2.4.0+ devices,

and sor far, for the fr45 I use jungle:

fr45.excludeAnnotations = older;LoG
fr45.sourcePath = $(fr45.sourcePath);infCIQ240-source;LowDraw-source
fr45.resourcePath = $(fr45.resourcePath);infCIQ240-resources

But I figured out that for exemple "pressure format" option even if don't loaded at runtime for the fr45 takes resources.

I found that I could do:

fr45.resourcePath = fr45-resources

and put in it all the resources needed for it, 

BUT doing this, will it ignore the language resources folders like resources-eng ?

Infortunately yes. In my app I have separate resources for devices that only have 16K memory, so for all of the 9 devices I have a section for each language like:

many thanks,

I've just made some test and it seems (on the simulatore) the string file is loaded, I talk about settings.

about the ones you talked about is it also for settings or runtime using?

on my side I did: 

fr45.resourcePath = e-resources;resources-round-208x208

in e-resources I put the defaut sting resource, (and all drawable etc )

and when I open the sim settings and change the language, it does work.