AppType-Suggestion: Activity Plugin

Very relevant to us.

We are trying to commerically sell a sensor that is capable of sending real time data to a Garmin watch.

However, there is a lot of data we would potentially like to show and the current limitations disable the user from seeing more than one variables at the the time. This is, because the datafield can not share its data to other datafields.

I get where you're coming from, but I doubt this will happen.

- creating a new app type which acts as a data provider for CIQ data fields is only going to cause user confusion. Users (including DC Rainmaker) still think that there's a distinct "widget" CIQ app type although that's no longer true for devices released in the past few years. What they think of as a widget is just a device app with a glance view.

Other bloggers debate the meaning of the word "app" in the context of CIQ, and it doesn't help that CIQ uses "app" 2 ways: to mean any kind of CIQ app (watchface, data field or device app) or to mean CIQ "device app" (what users think of as "apps".)

- devs asked for the ability to allow apps to share data and Garmin said they won't allow this for security reasons. The only exception they've made is complications, but obviously it's very limited and it only works for watchfaces

- if Garmin wanted to allow data fields to share data, it would be a lot simpler for everyone just to allow apps to share data directly, than to create an additional app type to facilitate this

- "In order to save resources, one could e.g. allow only one ActivityPlugin per Activity." On watches, Garmin already limits the number of CIQ data fields per activity to 2 (same as the limit 9 years ago when CIQ launched), despite the fact that CPU power and memory have been increasing steadily since then. Why would they allow a whole new app type to run during an activity (even if its just 1 instance), when they haven't even changed the 2-field limit once in 9 years (with the exception of one device, where the limit was raised to 3)? CIQ users and devs ask for a data field limit increase all the time.

Ig my point is things are the way they are because Garmin wants to save resources and bc they're worried about security issues, and I doubt that they will introduce a whole new app type to get around these restrictions bc I don't think a new app type really solves any of these problems. It only makes things more complicated. We already have issues where one CIQ data field can cause a completely unrelated CIQ data field to crash, if they both write FIT fields.

We would be better off trying to convince Garmin to "simply" allow apps to share data. Maybe it could be like complications, where one app publishes data and the other app subscribes to it.

https://forums.garmin.com/developer/connect-iq/i/bug-reports/allow-shared-storage-between-apps

9787675 said:

However, there is a lot of data we would potentially like to show and the current limitations disable the user from seeing more than one variables at the the time. This is, because the datafield can not share its data to other datafields.

You could implement a "full-screen" CIQ data field (which only works in a 1 field layout), which could then display several variables. Stryd Zones does this, as do many other popular CIQ data fields. In fact, this use case is so common that the official Garmin support article for installing CIQ data fields tells users to set the layout to 1 field (as if full screen data fields are the only kind of CIQ data field that exists.) Some devs have managed to cram up to 12 metrics in a single full screen field (see Dozen Run, for example). (6 or 8 fields per screen are more typical use cases tho.)

If you need more to provide more than one page of data, I can think of a couple of workarounds to allow the user to switch pages given that CIQ data fields can't receive user input:

- have your field switch pages when the data field is quickly hidden and displayed again (i.e. when the user quickly presses DOWN, then UP, while they're looking at your field.) The way I implement is this by detecting when onShow() is called very quickly following onUpdate() - e.g. within 2 seconds. When this happens, it means that the user must've scrolled away from the data field and back quickly.

This is pretty kludgy and unintuitive, but I've used it for a field that I use every day for personal use. Idk if any of my users take advantage of that feature tho.

- use on-device settings to allow the user to switch pages. This is much less kludgy but requires a lot of clicks / swipes so it's not possible for the user to quickly switch pages

Even if your CIQ data field could share data with other CIQ data fields, that wouldn't be much help since the user would still be limited to 2 CIQ fields (for watches). Since you're implying that your CIQ fields would only display one variable at a time, allowing CIQ fields to share data would increase the amount of data they can see from 1 variable to 2 variables. You would get a lot more benefit by using the existing "full screen data field" capability to display 6 to 8 (or more) metrics at a time.

Also, some users might be unable or unwilling to install 2 CIQ fields that basically have the same purpose, since there may be another field that they want or need to use.

thank for your detailed answer. i have some points here:

- creating a new app type which acts as a data provider for CIQ data fields is only going to cause user confusion. Users (including DC Rainmaker) still think that there's a distinct "widget" CIQ app type although that's no longer true for devices released in the past few years. What they think of as a widget is just a device app with a glance view.

a valid point. but in this case the AppType must not realy be visible to the User. if the DataFields had defined dependencies, they could be installed automatically. but i see that this might be a liddle far fetched.

- devs asked for the ability to allow apps to share data and Garmin said they won't allow this for security reasons. The only exception they've made is complications, but obviously it's very limited and it only works for watchfaces

but aditionally a new AppType would have the advantage that it might have more rights. using Sensor-data in DataFields would be great. if garmin does not want to allow that for DataFields in order to save resources, this might be a way.

...Why would they allow a whole new app type to run during an activity (even if its just 1 instance), when they haven't even changed the 2-field limit once in 9 years (with the exception of one device, where the limit was raised to 3)? CIQ users and devs ask for a data field limit increase all the time.

because they now have more resources ;)

But you are right. If at least DataFields could share resources somehow (be it by being able to not only write but also read the custom FitContributions) and if we could use SensorData like the Accelerometer in DataFields it would realy help.

also thanks for the constructiv feedback. splitting the DataField is propably the way to go, but its unnecessarily complicated in my opinion and brings a lot of overhead for something that should be easy.
another solution might be, if multiple DataFields could be defined in a single Project. There was a post arguing against that, but that was 8 years ago and especially the resources-argument should be reevaluated.

I'd consider doing a device-app that records an activity.  With that you can do things like have multiple screens to display all the data you want (one of mine has about a dozen screens for example)..  You can also use more fitContrib fields

Not sure what activity types your sensor would be used for, but you can make that configurable.  And you can access much more when it comes to buttons and touch.

You could still have a data field to use in native activities, but as someone up there in years with glasses, trying to show something like 12 things on a full screen DF might be really hard to see/use

As far as common code, look at using barrels.  I used them a lot at one time, but there is an overhead.

I now use the app's jungles file to pull in common code used in multiple apps.

jim_m_58 said:

You could still have a data field to use in native activities, but as someone up there in years with glasses, trying to show something like 12 things on a full screen DF might be really hard to see/use

A dev could still show 4-6 fields in their full screen CIQ data field and make many people happy. It would still be much better than the previously stated limitation of 1-2 values if you limit yourself to 1 or 2 non-full screen fields.

Stryd Zones is a commercial CIQ data field (it’s only useful if you buy a Stryd footpod), and it displays 5 metrics in mostly large fonts. It also has the ability to work in non-fullscreen mode, where it only displays 2 metrics (1 in large font.) Notice how Stryd didn’t limit their data field to non-fullscreen mode simply bc some of their users wouldn’t like fullscreen mode or wouldn’t know how to change the layout to 1 field. They put in the work to try to accommodate multiple types of users and use cases.

I have a full screen CIQ data field with a 6 field layout which happens to use the same font size as a 4 field layout, because of the way I arranged the fields and labels.

Again, as I pointed out, Garmin support for installing CIQ data fields literally tells people to change their data screen to “1 field”, without even mentioning the fact that some fields aren’t necessarily designed/optimized to be used this way. Clearly this indicates that the vast majority of popular CIQ data fields take up a whole screen. The reasons for this fairly obvious:

- 2 CIQ field limit means people usually don’t want to “waste” a slot on a field that only shows one thing (this is part of the very topic we are discussing)

- older watches only allowed up to 4 fields per page, so a CIQ data field that could display 6 fields (for example) was very useful. Even now, some watches only allow up to 6 fields per page, whereas some of the popular CIQ data fields typically show 8

- older watches only allowed a very limited number of data pages (e.g. 2), and some watches today only allow up to 4 pages (which limits the total number of fields for the entire activity). Again, any CIQ field that could display several fields on one page would likely add utility to the watch (although in this case, it’s a balancing act because you lose a whole page)

https://support.garmin.com/en-CA/?faq=gyywAozBuAAGlvfzvR9VZ8

jim_m_58 said:

I'd consider doing a device-app that records an activity

The problem with this is you have to reinvent the wheel for almost all the commonly used functionality that Garmin usually provides in native activities such as running. And all of those extra running features that the user paid a premium for? Either impractical or impossible to recreate. Basically if someone uses your sensor, you’re asking them to give up a huge chunk of functionality that they paid for and that they may actually be using. They may even want or need to use another 3rd party CIQ data field, which is impossible if they have to use your CIQ device app. (Which might be why some ppl asked whether it would be possible to use a CIQ data field within a CIQ device app.)

I used dwMap for years, when I had a Garmin that lacked navigation. It was great, considering that it was a free CIQ device app which gave me navigation. However, once I got a Garmin that had native navigation, I never looked back. No device app that a 3rd party dev could implement could ever truly replace the native running activity, and that’s obviously 100% by design.

I feel like a device app that replaces/implements a built-in sport/activity can only work in a limited number of situations:

- when the device app implements an unusual sport that doesn’t even exist on the device (or exists, but in a very limited form). One example is jump rope (before Garmin added support)

- when the device app implements an unusual use case that is either not possible in a native activity, or does more than the native activity. e.g. Structured workouts for stryd, your Hike app. Personally as a runner, I would never regularly use a 3rd party device app for runs, bc in some ways it defeats the purpose of using a Garmin in the first place (unless I had a basic Garmin which had very little native running functionality that I cared about). If it ever came to that, why not just use Apple Watch and something like WorkOutDoors? 3rd party apps can do so much more on AW.

I think that CIQ data fields are actually the best fit for the Garmin device model for the kind of use case where you’re selling a sensor / add-on to Garmin, as data fields are literally meant to augment existing activities. It’s just too bad there’s so many limitations (e.g. no user input).