property naming - must be lower case names?

That shouldn't be the case. Any valid string literal starting with a letter (basically, the same naming rules as with Monkey C variables) should work for property IDs.

I modified both our ApplicationSettings sample and ObjectStore sample app's properties to use camel case instead of underscores (e.g. "booleanProp" instead of "boolean_prop"), and they functioned normally in both the 2.4.6 and 3.0.0.beta2 SDKs.

Properties persist on the system, and the value defined in this XML is only a default value. Are you sure you are not seeing a value that has been changed to true by your application, or previously had a value of true? If either of these are the case, it will not change back to the default defined in your XML definition unless you uninstall/reinstall the application, or wipe the persisted data.

Yes it must be the persistence thing that is causing it. Have been banging my head on this one for a while.
I do not want to persist the value. Perhaps this is made worse by using the simulator, so when i run
different devices it gets persisted value from previous device. My problem is simply i need a flag i can read
to indicate models with larger memory vs those limited to 32 datafields.

What i want is a constant, not changeable, using jungle files to select different constant value for certain devices.
project.manifest = manifest.xml
base.resourcePath = $(base.resourcePath)
edge_1000.resourcePath = $(base.resourcePath);resources-largemem

This properties.xml containing true/false value like this.
<property id="large_mem" type="boolean">true</property>

I read the docs and found this, which lead me to believe that settings would persist, but that properties would not.

Properties are constant values defined at build time and includ ed in the executable that are useful for
product-specific values that shouldn’t be defined in code. Properties may also define the default
Settings values. Settings are user-editable values modified through Garmin Connect Mobile and
Garmin Express. Default settings values are defined by Properties.

If there is a way to clear the persisted value, i could do this in code, forcing it to re-read each time from
the appropriate default.


I had tried before doing a folder name like this without needing jungle files, it would hold the desired properties, but that also failed to work as expected.
/resources-edge_1000-edge1030-edge820-edge520plus

I'm not sure what the best way is to handle this. There may be some other developers with solutions to this problem that can chime in.

The first solution that comes to my mind is to add a source file that contains this constant. Create 2 (or more) versions of the source file, and use your .jungle file to include the appropriate one in each build.

My problem is simply i need a flag i can read to indicate models with larger memory vs those limited to 32 datafields.

if you just want to see how big the DF is (memory wise) you can just do it in a single line of code.

if(Sys.getSystemStats().totalMemory>32768) {

}


I do things like this in initialize() for DFs to set array sizes for data, etc

If it's not something that can be simply handled this way, I'd do what Brian suggested with the constant in different files, and use Jungle to build with the correct file for a device.

It seems to me that a property without the matched setting fields is the easy way to do this. Provided you never call AppBase::setProperty() or Properties::setValue(), it should not be a problem.

You could also do it with jungle files and build exclusions. Something like this..

# monkey.jungle
project.manifest = manifest.xml

# by default all devices exclude feature support
base.excludeAnnotations = no_awesome_feature

# these specific devices don't exclude the feature
fenix5.excludeAnnotations = has_awesome_feature
fenix5s.excludeAnnotations = has_awesome_feature
fenix5x.excludeAnnotations = has_awesome_feature


Then in a source file, you can do this..

module Configuration
{
// you don't need to name the variable the same thing as the annotation
(:has_awesome_feature) const has_awesome_feature = true;
(:no_awesome_feature) const has_awesome_feature = false;

// alternative
(:has_awesome_feature) const awesome_feature = true;
}


Then, in the place that matters..

if (Configuration.has_awesome_feature) {
// whatever
}

// alternative
if (Configuration has :awesome_feature) {
// whatever
}


If you find that you're using this technique to exclude lots of code, it may be a good idea to switch to using build exclusions. This is where you make different implementations based on whether or not some feature is available. It would go something like this...

# monkey.jungle
project.manifest = manifest.xml

has_awesome_feature = source/has_awesome_feature/Configuration.mc
no_awesome_feature = source/no_awesome_feature/Configuration.mc

# these specific devices don't exclude the feature
fenix5.sourcePath = $(fenix5.sourcePath);$(has_awesome_feature)
fenix5s.sourcePath = $(fenix5s.sourcePath);$(has_awesome_feature)
fenix5x.sourcePath = $(fenix5x.sourcePath);$(has_awesome_feature)

# all other devices use the other source folder.. as far as i can tell, you need one entry
# for each device that your app supports
fr920xt.sourcePath = $(fr920xt.sourcePath);$(no_awesome_feature)
.
.
.


// source/has_awesome_feature/Configuration.mc
module Configuration
{
const has_awesome_feature = true;

// alternative
const awesome_feature = true;

// other supporting stuff
}


// source/no_awesome_feature/Configuration.mc
module Configuration
{
const has_awesome_feature = false;

// alternative omits awesome_feature definition entirely

// other supporting stuff
}


I'm betting there is a better way to do the build exclusions so that it isn't quite so verbose, but that is what I've got right now. Maybe Marianne or Ken could chime in here.

Travis