set/getProperty deprecate on sdk 4?

"- there is a lot getProperty call and I think it may be connected with it but why if this in app memory and it's loaded when app start:"

I think it's more due to the size of all your properties (e.g. number of properties) and not the number of getProperty() calls.

As far as I know, if you send settings the classic way (not on-device settings), then it's like temporarily having two copies of your properties in RAM, for a brief moment in time.

Everything I said in my previous comment refers to off-device settings.

I don't own a device with on-device settings and I've never used them, so I was unaware that onSettingsChanged() is called when settings are changed on the watch. (My understanding is that it isn't, but I can't be 100% sure.)

developer.garmin.com/.../AppBase.html

onSettingsChanged() as Void

"- there is a lot getProperty call and I think it may be connected with it but why if this in app memory and it's loaded when app start:"

I think it's more due to the size of all your properties (e.g. number of properties) and not the number of getProperty() calls.

As far as I know, if you send settings the classic way (not on-device settings), then it's like temporarily having two copies of your properties in RAM, for a brief moment in time.

Everything I said in my previous comment refers to off-device settings.

I don't own a device with on-device settings and I've never used them, so I was unaware that onSettingsChanged() is called when settings are changed on the watch. (My understanding is that it isn't, but I can't be 100% sure.)

developer.garmin.com/.../AppBase.html

onSettingsChanged() as Void

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.