Missing CIQ 3.2 device in garmin store (Fenix 6 Pro Solar)

I have 2 versions of my watchface inside the garmin store. I checked that both versions have enabled all Fenix 6 devices and they do, it looks like following:

My older version has SDK version 1.2.X and my newer version has 3.2.X. So my question is, why does my newer version not support the Fenix 6 Pro Solar?

Inside the garmin store the supported devices do differ (quite a lot) for the fenix 6 models as well like following:

OLD VERSION

  • fēnix® 6
  • fēnix® 6 Dual Power fēnix® 6 Dual Power
  • fēnix® 6 Pro fēnix® 6 Pro, fēnix® 6 Sapphire
  • fēnix® 6 Pro Dual Power fēnix® 6 Pro Dual Power
  • fēnix® 6 Pro Solar fēnix® 6 Pro Solar
  • fēnix® 6 Solar fēnix® 6 Solar
  • fēnix® 6S fēnix® 6S
  • fēnix® 6S Dual Power fēnix® 6S Dual Power
  • fēnix® 6S Pro fēnix® 6S Pro, fēnix® 6S Sapphire
  • fēnix® 6S Pro Dual Power fēnix® 6S Pro Dual Power
  • fēnix® 6S Pro Solar fēnix® 6S Pro Solar
  • fēnix® 6S Solar fēnix® 6S Solar
  • fēnix® 6X Pro fēnix® 6X Pro, fēnix® 6X Sapphire, fēnix® 6X Pro Solar, tactix® Delta Sapphire, quatix® 6X Solar, tactix® Delta Solar, tactix® Delta Solar Ballisitcs

NEW VERSION

  • fēnix® 6
  • fēnix® 6 Pro fēnix® 6 Pro, fēnix® 6 Sapphire
  • fēnix® 6S fēnix® 6S
  • fēnix® 6S Pro fēnix® 6S Pro, fēnix® 6S Sapphire
  • fēnix® 6X Pro fēnix® 6X Pro, fēnix® 6X Sapphire, fēnix® 6X Pro Solar, tactix® Delta Sapphire, quatix® 6X Solar, tactix® Delta Solar, tactix® Delta Solar Ballisitc

That's weird, because both versions have all possible Fenix 6 models enabled (the exactly same devices as you can see in the screenshot) - so why is Fenix 6 Pro Solar not supported? I got the information from one of my users and he says, his device does run CIQ3.2. Actually I thought all Fenix 6 devices do support CIQ3.2 already...

  • I must really say that this system does not make much sense - it seems like so many things are just implemented by 50% and then released and then the devs should do whatever they can to solve the issues.

    As a dev, seeing that there is an option to select the min SDK, I want to be able to do this (otherwise this option should not be there). I decided to split up my app into two different versions because in one version I need background processes, internet and a lot of extra code for weather and in the other version I don't need this. My old watchface uses nearly all available memory on an device, my new one is far better now in many ways (size, memory usage, no background processes). I can exclude code at run time and check features at run time, but this comes for a price - more code, more memory...

    I told my users that if they can see my new watchface, there watchface has CIQ3.2 installed and they can use the new version, if not, they should stick with the old version. Now it seems that this is not true, some CIQ3.2 devices can't see my watchface although I've enabled them.

    To sum this up, as a dev, I don't want to care if a watchface is APAC or ROW. I want to know the model and the CIQ - that's all I need to know. And I should be able to set up everything correctly with this information.

  • APAC and ROW are actually different models even if they look to be the same.  And you can't use APAC devices in the sim.

    You got to understand that APAC FW may lag ROW FW by a month or two.

    I'm just letting you know how I handle things - and have done it this way for a number of years (since CIQ 1.0.0).  I never found that min CIQ was that useful, which is why I don't set it.  Selecting the targets as what's possible, and using "has" simplifies things IMHO.

    In the case of a WF that uses and external weather source or the Garmin Weather, having two separate apps makes sense (that's what I do), as it also impacts the permissions shown to the user.  The one with Garmin weather doesn't need 

    Run in the background when it is not active (potentially affecting battery life)
    Send/receive information to/from the Internet
    GPS location

  • So what's your suggestion for a watchface with weather feature that needs CIQ3.2? I decided to split my watchface because I wanted to get rid of unnecessary permissions and background processes.

    Now I do support all Fenix 6 devices and have splitted my watchface into 2 versions - although there is a min SDK it seems I must use a not very user friendly work around:

    • make my V2 version with min sdk 3.1 (or even less?)
    • tell the user to install V2 and try it - the watchface can then show it's informations or something like "your device does not support V2, please use V1" by making runtime checks with the  :has function

    That's all ok for me, but this is not user friendly, especially as min SDK seems to be there to solve exact this issue. The decision if a watchface is supported by a device or not should be part of the store, especially if the basic technology seems to be there...

    It does not make sense that a user uses V2 of my watchface if it is not fully supported - for those users I do provide V1 and I want them to use V1 as well.

  • Only have targets you think support 3.2, but include a "(Toybox has :Weather)" just in case.  Right now, the f5+ ROW devices have 3.2, but don't have weather, and you can handle it by removing the f5+ devices as targets, and for other devices (like the APAC versions, the "has" will handle it.

    Just because you can set the minimum, doesn't mean you have to.

  • Consider this.  Here are 2 watch faces I'm working on.  Both are basically the same, but one uses Garmin weather, the other data from Weather Underground

    the one with Garmin Weather

       

    The one with WU:

    While I could do some stuff with jungles to make them a single watch face, I won't do that.  You'll notice a difference in the info that's available, and also in the quality of the data.  If a user has access to WU, Garmin Weather won't be a preferred source.  

    Under the covers, the Garmin Weather version uses on device settings, while the WU version, just the standard App settings (I didn't want to mess with entering a 32 char API key on the device)

  • I'm trying to make it more clear, I really appreciate your help but it seems when it comes to telling me that a feature is there but I should not use it you avoid this wording?

    1. min SDK

    What can I use it for if I can't use it for what I wanted to use it?

    2. supported devices with CIQ3.2

    How do I find them? By setting the min SDK to 3.2 the manifest editor disabled all unsupported devices (e.g. also all Fenix 5 Devices). That's exactly the help I expect from the SDK and it's already there. Yes, some fenix 5 devices are missing, but that's ok for me, assume this will catch up with the real devices in the future. My goal is not to find all devices, CIQ3.2 is quite new, but to let the SDK decide how much "up-to-date" it is and let it tell me which devices to support CIQ3.2.

    3. your final suggestion

    Please don't defend the SDK, it's ok, but it seems (compared to what I'm used for) just not very developer friendly as problems developers are facing are not reliably solved but only partly... You would probably do following inside my watchfaces V2 version:

    • set min SDK to 1.2.X
    • use :has feature in code
    • enable devices that I think have CIQ3.2
    • show the user that their device is not supported if necessary (that's my decision, I want those users to use V1 of my watchface)
    • accept the drawback that the garmin store shows my V2 to people owning a device that's not supported (which does look like crap/junk to new users)
  • 1) Just because it's there doesn't mean you have to use it or it does everything you want.

    2) Sometimes it just a matter of looking in the platform forums and reading the latest release notes there.  And understand that FW support isn't always the same as SDK Device support.  The devices update can lag the FW updates, but under best case, it shouldn't take long. Having a simple app in your workspace that displays monkeyVersion can help to see what the sim thinks.

    3) Things are much better than in early 2015 when I started with CIQ.  I'm just passing on what works for me and has worked for a long time.

    What I do in my Hike and Hike2 apps is in the description just note that if a users device isn't supported to check "the other one" with a link. (Hike2 is only for devices with CIQ2 or greater, and using jungles, it will use on device maps or just draw a breadcrumb trail.)

  • 1) it is there - if I can not use it, it's useless... so that's not a good argument. I don't have to code my android apps in kotlin/java, I can write them in C as well, but why should anybody do this? It's still open what the min SDK is there for...

    2) here we have it again, the dev should find out basic changing things himself - it still seems for me that the min SDK should be there to avoid this manual process - garmin knows this stuff and should make it somehow available.

    3) I now now how you do it and thanks for the information here - in the end I will stick with my approach and hope the SDK will evolve and add new devices itself - and if the SDK says the device does not support CIQ3.2 so it is... I think an app that tells a user to use another version looks like an app from a bad developer (sounds like "I could not code it better so please try the alternative version and try it yourself")...

    We can discuss this further if you want, but regarding my initial issue everything is clear now but point 1

  • You can use it, but understand it may not work the way you expect at all times and for all devices.  I posted how I've done things for years to avoid the situation you have.  There are time differences between when a device gets FW and when the SDK/devices reflect that.  An interesting thing is in a case where there could be beta FW for a device, with say 3.2, but the production FW is 3.1.  The SDK will stay at 3.1 until there is production FW with 3.2, but using my method, users that do install the beta can make use of the new functionality.  This in fact has happened in just the last few months.

  • may not work the way you expect at all times and for all devices

    then it's not useful at all... something that works in some cases only and on some devices only and sometimes only is something that does not work.

    From other eco systems I know that this sort of thing works for more than 10 years without problems (e.g. the google play store). It does not matter what CIQ version is on a device normally or by default, it just does matter what really is installed on the users device.

    I would expect following:

    • the SDK knows which devices may run CIQ3.2
    • it allows me to select all devices that may run CIQ3.2 (not only some of them like currently)
    • the garmin store knows on which device my watchface will be installed - it can easily decide if it shows my watchface that supports all fenix 6 models to users with fenix 6 models AND CIQ3.2 installed (based on my developer decision of using min SDK 3.2) just as I've set it up in the manifest.

    For me the current solution isa bug or I don't understand the logic behind having a min SDK at all. I have not excluded any fenix 6 device, I defined that my watchface needs CIQ3.2 and still some hidden logic desides to not show my watchface to people owning a fenix 6 pro solar with CIQ3.2...