Ticket Created
over 4 years ago

WERETECH-11175

set/getProperty deprecate on sdk 4?

In current doc something has changed!!

Previous information: some function (e.g. deleteProperty) was planned to remove but not set/get.

My app run well and there are values in sim Application.AppBase.Data.

So, is documentation correct?

I have some strange app behaviour on sim:

- settings don't change

- memory peaks

- console  message "Unable to serialize app data"

- resetting settings to default

can be connected with any changes in sdk 4?

Parents
  • "We spend hours to fight with limitation of system, the worst it's keeping in my memory code, each lines of code lower my memory, most of variable has 1 or 2 chars, code is horrible."

    I agree that we have to write horrible code to save memory in Connect IQ, and that some of these limitations are very frustrating (you can see me complaining in the forums all the time haha).

    However, I don't think the length of your variable names matters (local, class or global variables) -- your variable names can be any length you want and they'll take up the same amount of code/data space in memory. You can def save memory by having fewer variables, and *maybe* by having fewer unique variable names (as a symbol as automatically created for each new name -- I'm just not sure if it makes a difference at runtime)

    The length of *property names* matters because they'll be stored as keys in the property dictionary.

Comment
  • "We spend hours to fight with limitation of system, the worst it's keeping in my memory code, each lines of code lower my memory, most of variable has 1 or 2 chars, code is horrible."

    I agree that we have to write horrible code to save memory in Connect IQ, and that some of these limitations are very frustrating (you can see me complaining in the forums all the time haha).

    However, I don't think the length of your variable names matters (local, class or global variables) -- your variable names can be any length you want and they'll take up the same amount of code/data space in memory. You can def save memory by having fewer variables, and *maybe* by having fewer unique variable names (as a symbol as automatically created for each new name -- I'm just not sure if it makes a difference at runtime)

    The length of *property names* matters because they'll be stored as keys in the property dictionary.

Children
  • ok, my minimal is 2.3 and when I've changed to 2.4 none of device was removed (maybe some part numbers, I don't know).

    As I understand module Properties should be use to obtain application's settings (even save new data - but not by background) and Storage to save data for later usage and exchange data between background and app, correct?

    checking sdk level by e.g.

    if(Application has Storage)

    {

     //access app's settings by Properties

     //access to storage by Storage

    }else

    {

     //access app's settings by getProperties()

     //access to storage by set/getProperties()

    }

  • "But what about with the subject of this topic, set/getProperty deprecation? On venu 2/2s sim everything run well it means not deprecated."

    Yeah, idk. The doc says not to use that API for CIQ 4 devices so maybe it won't work in the future.

    You could always switch to Application.Properties (getValue and setValue).

    I know it's a pain bc devices older than 2.4 don't support it. That's why I never use it, but I guess I'll have to if I ever want to support Venu 2.

    I don't think that SDK 4 itself can deprecate Applicatoin.AppBase.get/setProperty, bc as Brandon pointed out, it's supposed to work. Otherwise we won't be able to dev for old devices in SDK 4.

  • I know about properties name. But I think also name of id in in string (<string id="AppName">) and layout (<param name="locX">).

    But what about with the subject of this topic, set/getProperty deprecation? On venu 2/2s sim everything run well it means not deprecated.

  • And due to the way properties are defined and accessed, the original name has to be preserved. (They're stored in a dictionary where the property name is the key.)

  • "oh no... I've asked about several time and I was almost sure that length of var name has influence of memory consumption even though I felt it shouldn't."

    It's only the length of *property* names that have an affect on memory consumption, because properties are always loaded into memory.