set/getProperty deprecate on sdk 4?

You can say that length of var has no matters because all code exist in the same area of memory (and maybe additionaly when function is called).

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.

This my class declaration example:

           
    var     
            mVs,// = "",           
            mCT = 1,          
            mSV,               
            
            mVv,               
            mVn,                
            mVx,                
            mDn,                             mDx,               
            mValueRange,        
            mVl,               
            mVg,              

           AND SO ON...

and function

    function drawV(v, x, y, dc, c)
    {
        if((y == null) || ((mSV != null) && (v != null) && (v > mSV)))
        {
            return;
        }
horrible...

of cource I can save some memory removing m from members and use d instead dc or name dV instead drawV  - a lot place to reduce memory :)

the problem is whith Garmin code, not do anything e.g. getProperty should shorten to gP :)

You can say that length of var has no matters because all code exist in the same area of memory (and maybe additionaly when function is called).

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.

This my class declaration example:

           
    var     
            mVs,// = "",           
            mCT = 1,          
            mSV,               
            
            mVv,               
            mVn,                
            mVx,                
            mDn,                             mDx,               
            mValueRange,        
            mVl,               
            mVg,              

           AND SO ON...

and function

    function drawV(v, x, y, dc, c)
    {
        if((y == null) || ((mSV != null) && (v != null) && (v > mSV)))
        {
            return;
        }
horrible...

of cource I can save some memory removing m from members and use d instead dc or name dV instead drawV  - a lot place to reduce memory :)

the problem is whith Garmin code, not do anything e.g. getProperty should shorten to gP :)

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.