jungles/resources

As long as you’re okay with also losing all the other default resource paths (e.g. resources-semiround), just use:
fr235.resourcePath = resources-fr235

As long as you’re okay with also losing all the other default resource paths (e.g. resources-semiround), just use:
fr235.resourcePath = resources-fr235

well that doesnt help. :/

well that doesnt help. :/

Well, the resource system obviously only allows you to add or override paths, and not delete them. So unfortunately you have two choices here:
1) Add your own resource folders to the default resource folders for your target
2) Override the default resource folders completely (for your target)

Since 1) doesn't work with the scheme you have chosen then you either have to use 2) or rethink your scheme.

Unless of course you feel like going into SDKROOT/bin/default.jungle and recreating the fr235 resource path yourself, minus the "common" default resource path (resource)

i.e. From looking at default.jungle, the default resourcePath for fr235 is:
fr235.resourcePath = resources;resources-semiround;resources-semiround-215x180;resources-fr235


So you could simply use this (subtract resources):
fr235.resourcePath = resources-semiround;resources-semiround-215x180;resources-fr235


(If you added your own alternate resources to the base resourcePath, you would add them here too, preferably using local variables)

It's a hack and probably not recommended for many reasons, but it will work. You're not supposed to do this, but on the other hand, the default resource path should never change.

Otherwise you will need to rethink your scheme and explicitly specify resource paths for every single "class" or "family" of devices you support. If you are only making an exception for one or two devices, I'm sure you don't want to do that.

Personally, when I have resource differences (settings/properties) in a single app, it's usually based on CIQ level and/or available memory for data fields, so I actually do end up specifying extra resource folders for every single device. But what I do is also set up a default resource path which corresponds to a current-generation device, so there's greater chance of not having to make significant changes when new devices come out.

if "resources" has common stuff like the launcher icon and app name,
you could also have resources-fr235 for those settings and resources-vivoactive3 for those settings.

Hi,
In my jungle file i have:
fr235.resourcePath = $(fr235.resourcePath);resources-fr235

Sorry, to be absolutely clear, the default resource path for fr235 already includes resources-fr235, so that ^ part of your jungle file has no effect.

if "resources" has common stuff like the launcher icon and app name,
you could also have resources-fr235 for those settings and resources-vivoactive3 for those settings.

I think that only really works if:
- You only support a handful of devices
- Each device has different settings or you don't mind duplicating the settings.xml/properties.xml needlessly (or creating links or whatever)

To expand on what I was saying about explicitly listing all targets that have different settings, you could have something like this:

# e.g. Suppose you have two versions of your app settings:
# "Floors supported" and "floors not supported"
# And the folders are as follows
# resources-settings-floors/
# resources-settings-nofloors/

# Set the resource path for your "default" device here
base.resourcePath = $(base.resourcePath);resources-settings-floors

################################################

# List all devices that don't support floors here
#fr230.resourcePath = $(fr230.resourcePath);resources-settings-nofloors
#fr235.resourcePath = $(fr235.resourcePath);resources-settings-nofloors
#fr630.resourcePath = $(fr630.resourcePath);resources-settings-nofloors
#fr735xt.resourcePath = $(fr735xt.resourcePath);resources-settings-nofloors
# ^ We can cheat and say that we know that all semiround devices lack support for floors
# so we'll replace the above 4 lines with 1 below:
# (This especially works because there will probably be no new semiround devices in the future)
semiround.resourcePath = $(semiround.resourcePath);resources-settings-nofloors
#
vivoactive.resourcePath = $(vivoactive.resourcePath);resources-settings-nofloors
vivoactive_hr.resourcePath = $(vivoactive_hr.resourcePath);resources-settings-nofloors
#
# etc.


---

Another more maintainable approach would be: instead of subtracting the "floors" settings from devices that don't have it, you could add it to devices that do have it. That way you could keep base versions of your settings.xml/properties.xml that are common to all devices. This would allow you to keep common settings in one place, for ease of maintenance.

e.g.
# resources/
# settings.xml <= contains settings common to all devices
# properties.xml <= contains properties common to all devices
#
# resources-barometer/
# settings.xml <= contains additional settings for devices with barometers (can count floors)
# properties.xml <= contains additional property for devices with barometers (can count floors)

# List all devices with a baro below
fr920xt.resourcePath = $(fr920xt.resourcePath);resources-barometer
fr935.resourcePath = $(fr935.resourcePath);resources-barometer
fenix5.resourcePath = $(fenix5.resourcePath);resources-barometer
#etc.



Of course this imposes an order on your settings. The "floors" setting has to come first or last. You could get around this by splitting the default settings into "pre" and "post" sections (in separate folders), and putting the "floors" setting in the middle.

Sorry, to be absolutely clear, the default resource path for fr235 already includes resources-fr235, so that ^ part of your jungle file has no effect.



I think that only really works if:
- You only support a handful of devices
- Each device has different settings or you don't mind duplicating the settings.xml/properties.xml needlessly (or creating links or whatever)

To expand on what I was saying about explicitly listing all targets that have different settings, you could have something like this:

# e.g. Suppose you have two versions of your app settings:
# "Floors supported" and "floors not supported"
# And the folders are as follows
# resources-settings-floors/
# resources-settings-nofloors/

# Set the resource path for your "default" device here
base.resourcePath = $(base.resourcePath);resources-settings-floors

################################################

# List all devices that don't support floors here
#fr230.resourcePath = $(fr230.resourcePath);resources-settings-nofloors
#fr235.resourcePath = $(fr235.resourcePath);resources-settings-nofloors
#fr630.resourcePath = $(fr630.resourcePath);resources-settings-nofloors
#fr735xt.resourcePath = $(fr735xt.resourcePath);resources-settings-nofloors
# ^ We can cheat and say that we know that all semiround devices lack support for floors
# so we'll replace the above 4 lines with 1 below:
# (This especially works because there will probably be no new semiround devices in the future)
semiround.resourcePath = $(semiround.resourcePath);resources-settings-nofloors
#
vivoactive.resourcePath = $(vivoactive.resourcePath);resources-settings-nofloors
vivoactive_hr.resourcePath = $(vivoactive_hr.resourcePath);resources-settings-nofloors
#
# etc.


---

Another more maintainable approach would be: instead of subtracting the "floors" settings from devices that don't have it, you could add it to devices that do have it. That way you could keep base versions of your settings.xml/properties.xml that are common to all devices. This would allow you to keep common settings in one place, for ease of maintenance.

e.g.
# resources/
# settings.xml <= contains settings common to all devices
# properties.xml <= contains properties common to all devices
#
# resources-barometer/
# settings.xml <= contains additional settings for devices with barometers (can count floors)
# properties.xml <= contains additional property for devices with barometers (can count floors)

# List all devices with a baro below
fr920xt.resourcePath = $(fr920xt.resourcePath);resources-barometer
fr935.resourcePath = $(fr935.resourcePath);resources-barometer
fenix5.resourcePath = $(fenix5.resourcePath);resources-barometer
#etc.



Of course this imposes an order on your settings. The "floors" setting has to come first or last. You could get around this by splitting the default settings into "pre" and "post" sections (in separate folders), and putting the "floors" setting in the middle.

Thats great thanks for input. It looks like i really want the second option to let default settings for all devices and add some stuff for special.

so i created resources-vivoactive_hr where in settings.xml and properies.xml i have added floors. But when i built it and see app setting editor in eclipse it shows just default settings. I specified in jungle file
vivoactive_hr.resourcePath = $(vivoactive_hr.resourcePath);resources-vivoactive_hr


It looks like i am still doing something wrong.. or i need to test it directly on watches?

My additional settings.xml

<settings>



<setting propertyKey="@Properties.ClimbedDisplay" title="@Strings.ClimbedDisplayTitle">
<settingConfig type="alphanumeric" />
</setting>
<setting propertyKey="@Properties.DescendDisplay" title="@Strings.DescendDisplayTitle">
<settingConfig type="alphanumeric" />
</setting>
<setting propertyKey="@Properties.ClimbedMDisplay" title="@Strings.ClimbedMDisplayTitle">
<settingConfig type="alphanumeric" />
</setting>
<setting propertyKey="@Properties.DescendMDisplay" title="@Strings.DescendMDisplayTitle">
<settingConfig type="alphanumeric" />
</setting>


</settings>

and properties <properties>


<property id="ClimbedDisplay" type="string">0</property>
<property id="DescendDisplay" type="string">0</property>
<property id="ClimbedMDisplay" type="string">0</property>
<property id="DescendMDisplay" type="string">0</property>



</properties>

Thats great thanks for input.

No worries.

It looks like i really want the second option to let default settings for all devices and add some stuff for special.

so i created resources-vivoactive_hr where in settings.xml and properies.xml i have added floors. But when i built it and see app setting editor in eclipse it shows just default settings. I specified in jungle file
vivoactive_hr.resourcePath = $(vivoactive_hr.resourcePath);resources-vivoactive_hr


Couple of notes:

1) resources-vivoactive_hr is already part of vivoactive_hr.resourcePath (so there's no need to put that line in the jungle file if you want to do things this way)
2) There's nothing wrong with doing it this way, but this way you will have to have duplicate copies of setting/properties.xml for every single device that supports floors. Either that or you'll have to make links of some sort (either in Eclipse or using the OS). Personally, if I have one group of devices that has similar settings (e.g. baro-specific), I would create a common folder (in your case, resources-baro/ or something).

For example, in my data field apps I often have additional settings for CIQ 2+ (versus CIQ 1) watches, because of the additional available memory. So I have a separate folder called resources-ciq2.

It looks like i am still doing something wrong.. or i need to test it directly on watches?

I can't be sure this is the problem, but it sounds like you may not have built the app for the VAHR before opening the app settings.

The way device-specific builds work is sort of counter-intuitive -- in order to build a given device for the purpose of the app settings editor (and simulator), you have to run the app first. Automatic builds won't work in this case.

So this is the workflow for testing app settings in the simulator for a given device (e.g. VAHR), after making modifications.
1) Run app for VAHR
2) Open app settings (and change them)
3) Run app for VAHR (again)

Actually, with onSettingChanged (prefered), or always reading the settings in something like onUpdate(), you can skip step 3.

Run the app for the vahr, change settings (you should see the vahr version)...New settings take effect.

One thing to watch, is if you use a target with floors, then one without, the settings will have the properties you defined for floors. This won't happen on a real device. When you first run the target without floors, in the sim you may want to use file>reset all app data, so that everything goes back to the default for that target.
And while the settings/properties reflect floors/no floors, if you haven't done so already, use "have" or exclude annotations so the app knows what to do too.

I am kinda confuse now. Its still building just default resources. And no additional properties are load at app settings editor...community.garmin.com/.../1461819.jpg