set/getProperty deprecate on sdk 4?

"For me it's strange, when you analyse debug.xml there is numbers for object/function so every var, const etc should by change to number during compilation especially for "script language" when vm have to analyse every char and it cost memory and processor."

Monkey C isn't a "script" language tho. My understanding is that Monkey C is compiled into intermediate bytecode, like Java or C#.

I tried this a couple of years ago when I started playing around with saving memory in Monkey C, and I tried it today: I ran my app, then I changed the length of global, class and local variable names, and ran it again -- the amount of memory taken up at run time was identical in both cases. Notably, the code and data size did not change.

OTOH, if make a significant change to code -- e.g. replace if (x) with if (x != null) -- you will see the code size increase. And if you add a variable, you may see both the code size and data size increase.

But you can try for yourself. Just replace all instances of mValueRange in your code with mValueRange_ridiculouslyLongVariableName and see if there's any memory impact in the sim. I don't think there will be.

Note that to implement things like callback functions, you use symbols to refer to functions (and not strings). Symbols are also how one class refers to a field in another class. Note that the size of a symbol is constant and doesn't depend on the length of the identifier in code, as far as I can tell. I'm pretty sure that if you open a PRG file in a hex editor / text editor, you would see text for your property names and literal strings, but you wouldn't see text for any of your function or variable names.

"For me it's strange, when you analyse debug.xml there is numbers for object/function so every var, const etc should by change to number during compilation especially for "script language" when vm have to analyse every char and it cost memory and processor."

Monkey C isn't a "script" language tho. My understanding is that Monkey C is compiled into intermediate bytecode, like Java or C#.

I tried this a couple of years ago when I started playing around with saving memory in Monkey C, and I tried it today: I ran my app, then I changed the length of global, class and local variable names, and ran it again -- the amount of memory taken up at run time was identical in both cases. Notably, the code and data size did not change.

OTOH, if make a significant change to code -- e.g. replace if (x) with if (x != null) -- you will see the code size increase. And if you add a variable, you may see both the code size and data size increase.

But you can try for yourself. Just replace all instances of mValueRange in your code with mValueRange_ridiculouslyLongVariableName and see if there's any memory impact in the sim. I don't think there will be.

Note that to implement things like callback functions, you use symbols to refer to functions (and not strings). Symbols are also how one class refers to a field in another class. Note that the size of a symbol is constant and doesn't depend on the length of the identifier in code, as far as I can tell. I'm pretty sure that if you open a PRG file in a hex editor / text editor, you would see text for your property names and literal strings, but you wouldn't see text for any of your function or variable names.

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.