Ticket Created
over 3 years ago

CIQSTORE-2960

new settings are not visible after downloading new version for couple of days

Why the settings are not visible after updating the application?

Even changes to the labels are not updated immediately - I had to wait 2 days to new settings.

Settings are handled online (device's settings is available from 3.2.0 cost code/memory).

- new app + new settings

- upload to store

- accepting new vesrion for downloading  - FROM THIS MOMENT NEW SETTINGS SHOULD BE READY

- users can download new app

- for couple of days users cant' use new settings or they see old labels...

It means users have to use default values hardcoded (if developer doesn't forget to handle it and it's additional waste of time/memory because default values should be always returned as defined in properties.xml but they don't or rather they are after couple of days).

  • Problem is due to bugs in SDK so even documentation will say "it always return default value ..." it run for first bug and you have to checking - HAS, NULL etc...

    The bigger problem with wasting memory is necessity to use HAS because Garmin remove function from SDK. Let's see:

    - app min SDK 4.2

    - Toybox.ActivityMonitor.Info.metersDescended is from 2.1 but not for all device so I have to use HAS instead simple call for member and get null

    so code look like:

    if(info has metersDescended)

    {

      metersDescended  = null;

    }else

    {

      metersDescended  = info.metersDescended;//still can be null so I have to be prepare for null

    }

    instead simply  metersDescended  = info.metersDescended;

    Maybe there is some saving on device hardware but e.g. fr55 i f6s has exactly the same memory limit for app so there is no difference if I get 8 bytes more on fr55 or not because my app is prepare for f6s too and I have to be prepare for this 8 bytes.

    I don't know how SDK is prepared but it seems easier to have always all members and only def directive in function

    function getInfo_metersDescended ()

    {

    #ifdef FR55

    metersDescended=null;

    #endif

    #ifdef F6S

    metersDescended=getmetersDescended_fromSomewhere();

    #endif

    }

    and documentation is simpler - simple note "can be null"

  • "It means users have to use default values hardcoded (if developer doesn't forget to handle it and it's additional waste of time/memory because default values should be always returned as defined in properties.xml but they don't or rather they are after couple of days)."

    I agree that this is a waste of memory. There has been a similar situation in the past: if the user entered a non-numeric value for a number setting (for example), the app would receive null for that property, instead of the default value (or the previous value). I don't know if this is still the case, but due to that behavior, I had to hardcode defaults in my app too. It's also a shame that there's no way to programmatically retrieve defaults property values, for situations like this (or even for the on-device app settings case, if you have memory to spare).

  • strange, when I change settings (added/deleted keys not only labels) it was synchronised at once