• Replies 22 replies
  • Subscribers 20 subscribers
  • Views 1217 views
  • Users 0 members are here
Options
Related

AppType-Suggestion: Activity Plugin

deSHalb
3 months ago

Just for discussion. Please tell me what you think. This would solve a lot of the Issues we are currently running into, and - from what i can see - would somewhat fit into the Garmin-Ecosystem.

Currently Datafields have some Limitations (if i am missing something, please tell me!).

- If i were to use a little more complex calculations in a Datafield and i want to provide multiple Datafields based on the same calculations, i can not share the data and have to do it all over again for other Datafields. this adds a lot of overhead and is also bad for battery life.

- If i have an external Sensor providing data (which in my case i have) and i want to provide multiple Datafields based on that data, i would have to open up multiple connections (and in that case i am limited to 2 as far as i know). this adds a lot of overhead and is also bad for battery life.

- I dont have access to the sensor-data like accelerometers. this is propably to prevent datafields from doing complex calculations and in order to save battery-life, i get that...

My suggestion would be to have a new AppType, something like a ActivityPlugin.

In order to save resources, one could e.g. allow only one ActivityPlugin per Activity.

This one would:

- run in background of an activity

- have e.g. sensor-data-access

- can manage external sensor data

- do fit contributions

- "somehow" provide the generated data to the DataFields

One of the major challenges i see would be, that DataFields could depend on specific ActivityPlugins. Therefore one would have to have a good system in place that might automatically install an ActivityPlugin that is needed by a DataField (if not already installed) and it needs to be made transparent to the user of the watch if limitations arise (e.g. if only one ActivityPlugin could run at a time, DataFields that depend on different ActivityPlugins could not be active at the same time...)

  • 3 months ago in reply to FlowState

    Have you ever done a device app that records an activity?  They are often more complex than a data field, but also, much more flexible.

  • 3 months ago in reply to FlowState

    "You could implement a "full-screen" CIQ data field (which only works in a 1 field layout), which could then display several variables."

    We are aware of this feature but i have several issues with this concept:
    Many people (including myself) love to decide by themself what they want to see in a datafield.
    Somelike to see the pace, some the average speed of the current lap, some want to see in which HR area they are,,...
    There is an almost infinite number of possible combinations and deciding for the user what quantities are
    1) relevant enought to be shown and 2) in what size everything is displayed
    is a huge drawback.

    I guess 1) could be resolved by having a giant setting list for each displayed variable?
    If so it would still be clunky as the user would need to open an extra app on the smartphone to change a field which in other cases can easily be changed from the watch.(On device-settings are not allowed for datafields)

  • 3 months ago in reply to FlowState

    Sharing Data between DataFields is not the only issue i wanted to adress with my Discussion-Suggestion. 

    First of all it would enforce the intended role of DataFields as pure visualization-addons, whereas the ActivityPlugin i envision is for data-calculation. This in itself is good Softwaredesign.

    On the other hand, to fullfill that somewhat new role of a data-calculation/creation-addon, such a plugin could e.g. communicate with the internet (over the smartphone) and load data. provide life information from other sources. Do complex calculations on Sensor-Data and so on. 

    In my books this is not a complicated copy of a DataField, but rather a design that allows DataFields to stick to their role and not beeing hacked to do any kinds of stuff they are not realy intended to do.

  • 3 months ago in reply to jim_m_58
    jim_m_58 said:
    Have you ever done a device app that records an activity?  They are often more complex than a data field, but also, much more flexible.

    Uhhhh yes, I have. I actually found a bug where a device would crash if you stopped and started a recording too quickly. What I love about CIQ is basically anything any given dev looks at for the first time is almost guaranteed to have major bugs.

    I love the way I've been here for years but you always talk to me like it's my first post whenever I say anything you disagree with.

    And I already gave you props for your Hike apps which are a great example of how device apps can be very useful to the end user.

    My point still stands - personally as a runner, using an app to completely replace the native running activity defeats the purpose of using a Garmin in the first place (which is that I like the features of the built-in running activity). I own a Forerunner 955, and I bought it primarily for its running features.

    I'm aware of the flexibility of device apps, but did you read the part about reinventing the wheel? Have you ever used a running or cycling device app which comes close to providing the native functionality that comes with the built-in running/cycling activities on a FR255/265/955/965?

    Just a few examples in case you can't imagine what I'm talking about:

    - With a 3rd-party device app, you can't use native navigation to follow a course

    - With a 3rd-party device app, you can't use a 3rd party CIQ field (which I already mentioned). So for example, anyone who uses the Stryd Zones data field for running will not want to use a 3rd-party app for running

    - With a 3rd-party device app, you're probably not going to have good support for programmed workouts unless the developer decides to reinvent the wheel

    In a hypothetical world where CIQ running device apps are common and popular (they're not), do you think every dev is gonna take the time to add navigation and workout support (for example) to their apps, especially when their implementation will never be as good as the real thing? It makes sense if their app is dedicated to navigation or workouts, but not if they're just making a generic running app which focuses on their proprietary sensor or whatever.

    If I wanted to switch to a paradigm where a 3rd party app does almost everything, again it would make more sense to simply switch to Apple Watch, where it's normal to use a fully-fledged 3rd party app instead of native functionality.

    I don't know any runners who regularly run with a 3rd party device app on their Garmin. Most runners are not even aware of CIQ. At best they have Spotify and maybe a custom watchface. Very rarely do they use CIQ data fields, and they're even less likely to use a device app which replaces the running activity.

  • 3 months ago in reply to deSHalb
    deSHalb said:

    Sharing Data between DataFields is not the only issue i wanted to adress with my Discussion-Suggestion. 

    First of all it would enforce the intended role of DataFields as pure visualization-addons, whereas the ActivityPlugin i envision is for data-calculation. This in itself is good Softwaredesign.

    deSHalb said:
    In my books this is not a complicated copy of a DataField, but rather a design that allows DataFields to stick to their role and not beeing hacked to do any kinds of stuff they are not realy intended to do.

    I see your point, except Garmin has already defined a CIQ data field as something that performs both visualization and calculation.

    I see very little chance that they will change their minds about this.

  • 3 months ago in reply to FlowState

    The limitations with the access rights of DataFields make them feel more like mostly visualization-apps. Offcours i have little hopes for anything to change, but talking about it and suggesting solutions might help in the long run

    Maybe. One Day. In a few years or so... ;) 

  • 3 months ago in reply to deSHalb
    9787675 said:
    We are aware of this feature but i have several issues with this concept:
    Many people (including myself) love to decide by themself what they want to see in a datafield.
    Somelike to see the pace, some the average speed of the current lap, some want to see in which HR area they are,,...
    There is an almost infinite number of possible combinations and deciding for the user what quantities are
    1) relevant enought to be shown and 2) in what size everything is displayed
    is a huge drawback.

    Yes, I agree. Once you implement a full-screen data field, you have a new problem where users want to see all their favorite metrics on the same screen.

    Giving the user a huge list of of metrics to choose from is very clunky (it could be a drop-down with dozens or hundreds of metrics, given that Garmin's app settings - in the Connect IQ phone app - don't really support any kind of searchable or nested lists)

    For two of my full-screen data fields, I actually tried to mitigate this problem with a somewhat novel approach that I haven't seen anywhere else in the CIQ store - instead of giving the user a single flat dropdown list to choose from for each field, I give them 3 lists (2 modifiers + 1 metric)

    - 1st modifier: Overall (current/total), Lap, Last Lap

    - 2nd modifier: Average, Minimum, Maximum, or none of the above ("---")

    - metrics: Distance, Pace, Elevation, HR, Cadence, etc.

    For example:

    - "Lap", "Average" / "---", "Pace" (lap pace)

    - "Overall", "Maximum", "Heart Rate" (max HR)

    - "Overall", "---", "Cadence" (current cadence)

    In this way my apps can support 100s of combos of modifiers and metrics without requiring the user to select from a single drop down that has 100s of options. I can even support very obscure permutations of metrics that Garmin itself doesn't support, such as Last Lap Max HR or (overall) Min HR.

    Ofc none of that helps if the list of actual metrics (not modifiers) becomes too large.

    But again, if you are going to limit yourself to one value per field, then the 2 CIQ data field limit (for watches) is insurmountable. Even if Garmin allowed communication between data fields, you would be able to provide the user with 2 whole metrics, and that's assuming they are willing to use both slots.

    Again, there is a reason that Garmin support tells user to set the page layout to 1 field when they install a CIQ data field - they know that most of the popular fields are full-screen fields, for the current and historical reasons I mentioned above.

    As far as deciding what size everything is displayed in, you can support a fixed number of layouts (e.g. 1 field and 6 fields), and simply display every metric at the max size possible. (Yeah I say "simply", but actually some devices have an issue where there's a lot of white space padding in numerical fonts, so you might have to take that into account when you auto-size your fonts if you want to make the best possible use of space.)

    9787675 said:
    (On device-settings are not allowed for datafields)

    As previously mentioned, yes they are. (For all modern devices supporting CIQ >= 3.2.0, anyway)

    [https://developer.garmin.com/connect-iq/core-topics/properties-and-app-settings/#ondevicewatchfaceanddatafieldsettings]

    It would still be clunky for the user to change complex settings on the device (as this would require many button presses and swipes, and you're limited in the amount of information you can display at once), but at least you'd be able to implement nested menus for selecting metrics. However, the fact that Garmin somewhat recently introduced "Live Device Settings" where you change your device settings in the Connect app instead of on the device kinda shows that some users don't like changing settings on the watch itself. Even though the live settings are kind of slow, they are still superior in some ways to setting stuff directly on the watch (especially when configuring activity data pages.)

    Personally I would prefer for the Connect IQ phone app settings to be a lot more flexible and usable, but as it stands, it's not even possible to have simple text as separators or to render newlines within a label, and advanced features such as groups and arrays don't work.

    I once toyed with having an external website to configure one of my apps to reduce complexity and improve usability, but the problem is the act of actually getting the settings to and from the site adds too much complexity for the end user, and that I'd still have to support normal app settings anyway.

  • 3 months ago in reply to deSHalb
    deSHalb said:
    talking about it and suggesting solutions might help in the long run

    I don't have a problem with this, but I also want to be realistic.

    Once you've been in the CIQ ecosystem for a while, you'll see that things change very slowly, and many things never get fixed.

    I don't see a huge chance that Garmin will radically redesign its app ecosystem to make it more complex.

    They have actually gone in the opposite direction a few years ago, when they merged the "device app" and "widget" app type in order to simplify things. This was actually a very good thing (except for one use case that I won't go into which I felt was badly handled), but it's funny that bloggers and end users don't actually realize Garmin did this. They think that "widget" CIQ apps are a still a thing.

  • 3 months ago in reply to FlowState

    Thanks a lot for the informed discussion!

    We will probably give the full screen datafield a shot.

    I find your arguments against a full app very compelling. I once programmed such an app to have acces to the sensor data and it works fine, but the look and feel is just not the same. No programmable intervalls, no navigation, ..
    As you said, it cant compete.

    A full datafield has its own drawbacks but they might be worth the effort. One last question:
    How would you realize if the datafield is currently beeing displayed in full screen or in a single slot?

  • 3 months ago in reply to 9787675
    9787675 said:
    the look and feel is just not the same. No programmable intervalls, no navigation, ..
    As you said, it cant compete.

    Yeah exactly. I really think there's a very good reason that there are no popular, fully-fledged running or cycling device apps for CIQ, unlike WorkOutDoors for Apple Watch (which is touted as a Garmin killer).

    CIQ device apps can't compete with the "flagship" native activities (running, cycling and swimming) by design. Why would a user pay extra $$$ for 265/965 over 165 if they could simply get a $5 CIQ device app which does all the same stuff and more?

    9787675 said:
    How would you realize if the datafield is currently beeing displayed in full screen or in a single slot?

    In onLayout(), you could compare the size (width/height) of the data field's DC to the size of the device display. If the data field's DC is significantly smaller, then you can't be in full screen mode.

    (There might be some cases where a data field's DC is just a *little bit* smaller than the device DC. I do know that Venu SQ has a reserved "scrollbar-ish" area on the side of the data page which shows up as a blue line in the simulator. I think that blue area is not part of the field in a 1-field layout, but you can double check the device reference linked below.)

    For the exact dimensions of various data field layouts, you can check the device reference guide:

    https://developer.garmin.com/connect-iq/reference-guides/devices-reference/

    Note that some of the newer layouts (like 8 fields) are missing for some devices. But the 1-field layout should be there for every device that supports it (I forget if there's some obscure device which doesn't)

    So in the worst case, in order to handle some of those edge cases with the reserved areas, you could hardcode some of the checks.

    You can also see similar information in simulator.json for each device, in the layouts.datafields.datafields array.

    e.g. fr965/simulator.json:layouts.datafields.datafields[0]:

    {
    "drawBorders": true,
    "fields": [
        {
            "data": {
                "font": "numberThaiHot",
                "justification": "center",
                "width": 425,
                "x": 227,
                "y": 276
            },
            "label": {
                "font": "simExtNumber2",
                "justification": "center",
                "x": 227,
                "y": 126
            },
            "labelDisabled": false,
            "location": {
                "height": 454,
                "width": 454,
                "x": 0,
                "y": 0
            },
            "obscurity": [
                "left",
                "top",
                "right",
                "bottom"
            ]
        }
    ],
    "name": "1 Field"
},

    Also I confirmed that for venusq (for example), the device display resolution is 240x240, but the 1-field layout is 220x240.