How to create running app similar to standard Garmin running app?

You are correct.

A CIQ device app/activity can not use native or CIQ data fields.  You need to calculate and draw everything in you app.

Yeah.

That's why you don't see a lot of device apps in the store which are intended to literally replace a standard, feature-rich Garmin sport like running (even though that's supposedly one of the use cases for device apps in the first place). 

In some ways, using such an app defeats the purpose of buying a Garmin with a ton of fancy features, as you lose access to many of those features once you're not using a built in activity profile.

There have been a handful of device apps that replace a standard, feature-rich Garmin sport, like dwMap, but I think the functionality that it brings has to be really compelling. In the case of dwMap, it brought navigation to Garmin devices for free, when a lot of midrange Forerunners did not have it. I used it a lot when I had an older midrange Forerunner. As nice as it was, it could never deliver the same user experience and features as the built-in running app. As soon as I got a more expensive Forerunner with built-in navigation, I stopped using dwMap forever (as nice as it was).

Thank you for the clarification. It is very useful.

Ideally, it would be nice to have something like "Extend standard running app", otherwise, we really cannot develop compelling sport apps, as you said. It will take ages to implement all these features of the standard app, and many of them is not possible at all :(

If you think there's something that needs to be extended in a native activity, you can do it as a CIQ data field.

My hiking/walking apps took a bit of time to include all I wanted, but also have up to 12 data screens.  It can be done.

This works well for calculating/displaying information (which granted is that vast amount of use cases), but misses the ability to override something like OPs use case of tweaking the lapping logic, or misses the ability to take user input. For things like that the extending of a native activity would be ideal.

Check out my Hike2 app that does it's own laps and handles user input.  

https://apps.garmin.com/apps/116a5b59-29ae-4397-a70e-907d7e5f8e44

It's my own device-app/activity, all done in CIQ.

As far as user input in a watch data field goes, there's a couple of ways you can *sorta* take input, but none of them are perfect:

- Abuse the onLap event.

Obviously this comes with the downside that the user will also have to take a real lap

- Abuse pausing/resuming the activity.

Similar downside to above

- Abuse the on-device settings feature to take input for things unrelated to settings.

Ofc the problem here is it's a lot of button presses / taps to get to on-device settings in the first place. One limitation of on-device settings - last time I checked - is that the view you push will not be updated if you call View.onUpdate (e.g. from a timer). It only updates on user input (e.g. button presses), which means it can't be used to display dynamic secondary data (for example).

- Newer watches allow complex data fields to receive taps.

This is nice - probably the best alternative - but is obviously contingent on the user leaving the touchscreen enabled, so it can't really be used for critical functionality. Another issue is that the simulator doesn't reflect the real device behaviour here, so it might be hard to know exactly which watches support taps in data fields.

- Abuse the onShow/onHide events.

I do this in one of my data fields to "switch pages" when the user quickly presses UP, DOWN or DOWN, UP. This is obviously not user-friendly and it's probably the worst option. One problem is that onShow()/onHide() isn't called predictably across all watches. On older watches there's a certain sequence, while on newer watches, onShow() is called several times while the field scrolls away (presumably because the field is still being displayed as it's smoothly scrolls off the screen).

What I do is if my data field sees onShow() within 2 seconds of the last onUpdate(), then I assume it was hidden and shown very quickly, so I trigger an action (like switch pages) based on this "gesture"

In practice, on older watches, this is triggered when the user scrolls back to the data field. But on newer watches, this is triggered when the user scrolls away from the data field. Due to the way my app works, the distinction doesn't matter.

I probably wouldn't use this option because:

- it's user-unfriendly

- it varies between devices

- the real device behaviour is not reflected in the sim (it's not even possible any moreto trigger onShow/onHide events for data fields)

--

If you have critical functionality that requires some sort of input, the best alternative would probably be on-device settings, but then again, this will only work if the input isn't super time-sensitive.

BowersPowers said:

For things like that the extending of a native activity would be ideal

Maybe in 2035 :/

But seriously, CIQ is 10 years old. At this point, I don't see Garmin adding this feature. Maybe they'll prove me wrong though.

I think it's largely by design that no device app can really compete with built-in activities. 

BowersPowers said:

or misses the ability to take user input. For things like that the extending of a native activity would be ideal

But Garmin would never allow devs to override input handling in a native activity for the same reason they don't allow it now. 

Right now all native activities have a certain user experience when it comes to input. On a 5-button watch, every button has a specific function during an activity:

- START: pause/resume activity

- LAP: take a lap (or return to activity if you're in a menu)

- UP/DOWN: scroll

- LIGHT: turn the light on/off

There's literally no buttons left for CIQ data fields to use. Even the long presses are taken:

- Hold LIGHT: controls menu

- Hold UP: open (context-sensitive) menu

- Hold DOWN: open music controls / change sport / user-defined hotkey

- Hold START: user-defined hotkey

- Hold LAP: user-defined hotkey

Garmin doesn't even really allow device apps to use the long-press actions, except for hold UP. The other options are off the table as:

- apps can't detect / override hold LIGHT

- the other long-button presses might be used for user-defined or system default hotkeys, which means that no app can rely on them. You could detect them as an *option* as long as you're willing to concede that some users won't be able to use them in your app

What would really be great is if CIQ data fields could an option to the "context-sensitive" menu that's displayed when you hold UP, similar to how the map page has Pan/Zoom, Around Me, and Save Location entries before the standard menu entries. It would be great if you could push a fully functional view when the user selects this custom menu entry (not just a "settings" view which can't be updated dynamically).

It would also be nice if the data field on-device settings were directly accessible from the same menu.

Honestly this request could be fulfilled by:

- moving the CIQ on-device settings menu entry for each CIQ data field on the current page to the top level menu

- allowing the on-device settings view to be dynamically updated

I can see how this might be a problem if a user has 2 CIQ fields on the same page (or especially 4 CIQ fields on the same page, for newer watches). There would be similar issues if Garmin implemented this on Edge devices, which have some ridiculously high limit for the max number of CIQ data fields per activity.