Data Field: AppBuilder

...continued

I can tell you that people have mentioned they want to see average cadence excluding zeros, but when you mention there's an app where you have to type in a formula, they're not interested. You can imagine their eyes glazing over. And I kinda don't blame them. But am I gonna write a dozen apps for "Average Power, not including zeros", "Average Cadence, not including zeros", "Three Second Average Cadence", etc.? Probably not.

There's probably a happy medium where you have an app that shows a specific value with some configuration, and I've seen some niche apps that are just like that on the store. I'm not really interested in churning out that kind of app (although I have 3 of them, based on user request). And there's plenty of devs who'll do it in my place.

TL;DR I think people would use AppBuilder if:
- They have absolutely no other choice. See: Stryd
- They enjoy coding (weird....)

Update - AppBuilder Classic and 5

Fix recent issue where metric and statute units were swapped. Sorry about that!

Good news, recording works and power is transmitted to 3rd party sites like Sporttracks and Training peaks. :) I even get average power and lap power (under Appbuilder 5 IQ tag) in Garmin Connect, which is something I don't get using the Stryd IQ field.

Any of the data isn't transmitted to Stryd Powercenter though (I guess they only download data created with their own datafield), which might be a a showstopper for some, but for me it doesn't matter as I hardly ever use Powercenter for analysis anyway.

Either way, here's the formula I used for my first run:

RECORDLAP(ROUND(LAPAVG(NONZERO(Power))),19) ; RECORDSUMMARY(ROUND(AVG(NONZERO(Power))),20) ; RECORD(ROUND(TIMEAVG(NONZERO(Power),5)),7)

I added NONZERO as I noticed during testing that it actually does help with the dropout problem. I rarely stop during my runs and even when doing intervals I'm at least walking during the rest periods so it's better with than without. I also added 5s averaging for recorded power data as this also minimizes minor drop outs. Most of the time these only happen if I leave my hand on the watch longer time (several seconds) when pressing start or lap. Stryd itself has a 5s lag so 5s averaging doesn't add lag, but actually creates a much smoother graph than without, also NONZERO helps here with minor dropouts as long as they're shorter than the 5s averaging buffer.

Only thing that is still a bit mystery is that the recorded data is shown in decimal format in Garmin Connect, even though I've set as "number" in configuration settings. Anyway that's hardly a show stopper. Adding ROUND helps here as then data is at least shown as something like 255.00 instead of 255.4234312 (in lap view) and 255.40 in graph view.

All in all, I have to say amazing work so far actually making this possible. Now I have a perfect combination with DIY datafield as my main workout screen and Appbuilder recording the power data. Now I can even modify the recorded data with an appropriate formula on the fly.

JTH9 sorry, the FIT data format (decimal vs. number) is just like the graph/lap/summary labels - it's totally fixed at app build time, so it can't be changed dynamically. BTW, the extra decimal places in lap view is a bug. I forgot to limit the precision to 2 for laps. Thanks for catching that. That's a quick fix.

Glad you're finding it useful. FYI, I added Edge support to the full-screen AppBuilder+ data field, which should be approved sometime early next week.

I'll just leave the link here so I don't have to spam the thread again in a few days.:
https://apps.garmin.com/en-US/apps/3...b-fdcfbc877f3a

Ok, something I suspected. I guess it's difficult to fit a multipurpose field perfectly in the Garmin ecosystem. I see you did the same with the label thing. Works in mobile where it displays the label, but in GC web only shows 0 instead of label. Kind of sucks living with limitations you can't overcome. Still it works, these are very minor things and purely cosmetic.

I briefly even thought about upgrading my watch to take advantage of the + version, but I guess I'm already spoiled with the freely customizable layout of the DIY datafield, even when it has a few bugs like average power not displayed for first lap in running mode.

Anyway I guess this is pretty much as close I'll ever get without starting to code my own data field. Unless there will be a DIY datafield type web designer app with Appbuilder formulas and recording for each data slot. ;) I guess this would max the memory limit of even better devices quite quickly...

I think all the devices that support AppBuilder+ wouldn't have too many problems (*) with a (basic) DIY + AppBuilder+, but the real question is whether it's worth coding. The market is pretty tiny -- is DIY data field still being supported?

(*) Pretty sure they all have more than enough memory to support 6 formulas -- the only problem right now that I can think of is that even on large memory devices, AppBuilder can still fail if your formula is too complex, because it could take too long to process on startup. This problem is multiplied by 6 with AppBuilder+.

However, if you move the formula processing to a web app (and have users copy over encoded data into settings, like DIY), then it's pretty feasible. AppBuilder+ could theoretically already take custom layouts with a small tweak which wouldn't add a lot memory usage or startup time -- it would just be a matter of being able to build and configure them.

Out of all devices that support AppBuilder+, the 645M has the smallest amount of memory (64 KB), which is still twice as much as the next best watch. And all of the other AppBuilder+ devices (Fenix 5X, Fenix Plus, Edge) have 128 KB. And 645M still has about 20 KB left to play with.

To put that in perspective, if you set 1 field up with timeavg(X, 1200) (20-minute average!), that would take about 6 KB and the 645M could easily handle it, while none of the older devices could come close.

If you start adding icons and charts, that might be another story. Another open question is what the performance would be like for a data field like that -- would it slow down your whole watch?

The nice thing about a web app is that it could validate your formula, help you build it, and allow you to type it on multiple lines if it's long. Longer formulas could be supported, too,

But in the end, is this something people really want? I guess if it's visual, there could be more interest.

Just looking at downloads of DIY, it doesn't seem to interest that many people, even when no coding is involved and you could basically have just the kind of data field you want. I guess most people just rather have something that is ready to use. I think the developer has stopped updating it, but the designer page is still available, not sure for how long though.

I think it would be cool, but I guess I'm in the minority. :)

Btw, I just realized, since I went with nonzero 5s timeavg for the recording I now have to copy it to all formulas to perfectly match the lap and total workout summary with recorded data. It's not a big difference, but might be slightly off (like 1-2W at most) on short laps.

RECORDLAP(ROUND(LAPAVG(TIMEAVG(NONZERO(Power),5))),19) ; RECORDSUMMARY(ROUND(AVG(TIMEAVG(TIMEAVG(NONZERO(Power),5),30,1)^4)^0.25),34) ; RECORD(ROUND(TIMEAVG(NONZERO(Power),5)),7)

A bit overkill I know, especially since the drop out issue is quite rare and can be mostly avoided, just wanted to test what is possible. Based on a quick test, data seemed to match and it didn't crash (at least yet). I also switched average power to normalized power. Mostly these are used to record summary data in Garmin Connect as other sites could just calculate it from recorded power data.

I also understand that DIY won't perfectly reflect at this point what is recorded on shorter laps (I did set current power to show 5s average though), but like noted the difference will be negligible. Anyway will test like this for now and might switch it back to "real time power recording" at some point.

Update 5.9.9

Fix broken prevd()/prevt()

JTH9 AppBuilder should not crash in the middle of an activity.

Barring any bugs, the possible places for a crash are:
- At init time, if formula too complex (and/or FIT file recording enabled)
- At start time, if you run out memory - combo of formula complexity, FIT file recording and samples to timeavg[]

There's another problem with AppBuilder -- it exposes "dev problems" to the user which even devs don't want to think about. Imagine how many problems the full-screen data field will have with 6 formulas. I guess the good thing is most of those watches have lots of memory.

I think AppBuilder is great for tiny one-off formulas like "strength set" = "lapcount div 2 + 1", but that's about it.

Although I've owned 4 Garmins in the last 5 years of running <_<, I would never buy a new watch just for an app.... Think of how old and busted your shiny new Fenix 5X Plus will be in just 2-3 years. I'm thinking of all the Fenix 3 users who got mad because their watch didn't get CIQ2. At one point, Fenix 3 was top of the line, and now it's worse than a VAHR in some ways.

[It all started with an FR210 with horrible buttons that were hard to press and a start button that broke after a year -- it would only respond to hard mashing. I was so desperate to keep that watch that I would start the timer an hour before a workout or race, and just press Lap when I wanted to really start my activity. Maybe I should've kept that watch.]