Sharing object store parameters between applications/widgets/watchfaces/datafields

You can use "app settings" from Garmin Connect Mobile or Garmin Express to configure a watchface, widget, watch-app, or data field.

CIQ apps can not configure other CIQ apps on the watch itself.

What are you trying to do? There may be other ways to do it.

The through going around in my head is how to configure a user preference for a datafield. Like let's say that I wrote a datafield that counted down remaining distance in a marathon... a user configured parameter to select miles or km or fathoms or angstroms. Is this in one one of the SDK examples? Thanks.

Using App settings as jim_m_58 suggested is probably what you're after. The ObjectStore sample demonstrates how to use app settings on the second page of the app (swipe left). The relevant bits of code are mostly in DefaultPropertiesView.mc in the project, and the <settings> section of properties.xml.

I can explain my personal needs for object store sharing:
in my application I have configuration menu system and I cannot use inbuilt menus since my menu items are not static, their names and/or count changes depending on different application states. So, even to display such menus, I had to implement my own custom view/delegate, create wrapping code to call these menus in sequence etc. Adding this functionality ate about 15kb of application memory, and it seems that to expand basic functionality I need either to move this configuration to external facility (since Garmin mobile doesn't provide any flexible configuration of parameters this will make configuration application mobile OS dependent), or remove this logic completely.

In inbuilt Garmin running/cycling apps there is always a dedicated "settings" application. This helps to use precious watch memory and resources during actual activity recording in more efficient way. It's very unfair, that we cannot create such configuration activities using Garmin SDK and are made to either use rather unreliable and unflexible Garmin configuration options or create nice and effective but mobile OS dependent configuration facilites.

The point is: there IS a neccessity to have object store sharing, please, Garmin devs, consider this for future SDK releases.

You might be able to do it with a phone companion app, but that isn't available for data fields.

There may be some issues with one app's setting having unwanted side effects in others, if there are shared settings.

There may be some issues with one app's setting having unwanted side effects in others, if there are shared settings.

This explains it right here. In order to share the ObjectStore, we'd need controls so that permission can be given to allow an app to modify another app's ObjectStore. That is a pretty complex issue that we don't have a good solution for at this time.

This explains it right here. In order to share the ObjectStore, we'd need controls so that permission can be given to allow an app to modify another app's ObjectStore. That is a pretty complex issue that we don't have a good solution for at this time.

For me the most obvious solution is to add new class extending AppBase, that will require parent application UUID at initialization time much like in the mobile companion application we need an UUID for connectIq.getApplicationInfo(...). This will guarantee, that parent app ID remains constant during this "settings" app execution after it is submitted for publication. Of course, since anyone can currenly see app UUID on market, it is possible that people could try to create an application tampering with someone's else settings, but this will just disrupt that application object store leading to IQ error during start unless they somehow know the structure of properties/settings. The only security breach I can think of for this kind of implementation appears only if parent app uses Communication module and stores some kind of login information in properties. To get rid of this possible issue it's enough to hide store app id from anyone but actual developer (I don't know about AppStore, but on Google Play developer can get their app ID only in secure developer console area).

I understand that there could be other possible security issues I didn't consider, but this concept seems solid this far.

In my case I will certainly move some comprehensive settings to mobile application, but, once again, this is not the best solution since bluetooth connection may not be available at all times (I may be wrong, but in my understanding one of the selling points of Fenix3 and Epix watches is positioning them as a standalone device for tourists).

Of course, since anyone can currenly see app UUID on market

AFAICT, the app UUID specified in the manifest is not the same as the one used to identify your project in the app store.