Announcement

Collapse
No announcement yet.

Okay to have different CIQ settings for different devices?

Collapse
X
  • Time
  • Show
Clear All
new posts

  • Okay to have different CIQ settings for different devices?

    I'm sorry if this is an obvious question or if it's been addressed already, but is it possible to have different settings for different devices? e.g. Different sets of app config for CIQ1 devices versus CIQ2+ devices

    To me it seems that the answer should def be yes, because there is a different PARTNUMBER-settings.json in the IQ file for each folder (corresponding to a part number), which contains settings, strings and properties, and I'm sure that the latter two can vary by device.

    However, I have seen a couple of apps which have certain settings that only apply to certain devices, and (apparently) instead of selectively adding/removing them from individual devices using conditional resources, the settings label simply says "This setting applies to Epix only" (or whatever).

    Is there something I'm missing where all devices need to have the same settings? (Like some constraint on the store side).

    Thanks!

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

    simple example:
    Code:
    fenix3.resourcePath = $(fenix3.resourcePath);_jungle/fenix3_settings.xml
    
    fenix5.resourcePath = $(fenix5.resourcePath);_jungle/fenix5_settings.xml
    My best Connect IQ apps:Other:

    Comment


    • #3
      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.
      Last edited by FlowState; 11-08-2018, 07:49 AM.

      Comment


      • #4
        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.

        My Connect IQ Apps in the Store
        Facebook - Instagram -
        Twitter

        Comment


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

          Comment


          • #6
            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.
            My best Connect IQ apps:Other:

            Comment


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

              Comment


              • #8
                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.
                Last edited by FlowState; 11-08-2018, 12:03 PM.

                Comment

                Working...
                X