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
  • [quote userid="281968" url="~/developer/connect-iq/f/discussion/262197/set-getproperty-deprecate-on-sdk-4"]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 [/quote] I've seen similar behavior (settings don't change and/or settings are reset to default) when running low on memory for data fields, in both the simulator and the real watch. (Even in SDKs earlier than 4). It's possible that just building for a new SDK means that your app is using more memory than before. Is the current/peak memory usage for your app higher in SDK 4 than it was for earlier SDKs? The only workaround, as far as I know, is to close the app before sending settings (both for the real device and the sim.) In the sim, you can use File > Kill App to close the app without closing the sim.
Comment
  • [quote userid="281968" url="~/developer/connect-iq/f/discussion/262197/set-getproperty-deprecate-on-sdk-4"]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 [/quote] I've seen similar behavior (settings don't change and/or settings are reset to default) when running low on memory for data fields, in both the simulator and the real watch. (Even in SDKs earlier than 4). It's possible that just building for a new SDK means that your app is using more memory than before. Is the current/peak memory usage for your app higher in SDK 4 than it was for earlier SDKs? The only workaround, as far as I know, is to close the app before sending settings (both for the real device and the sim.) In the sim, you can use File > Kill App to close the app without closing the sim.
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.