Data Field: AppBuilder

All the average functions ignore nulls, though. I can’t speak for power, but I know that if you’re not wearing your watch or HR strap, HR is null. I would assume any kind of sensor dropouts would return null, not 0.

I specifically put the “ignore zeros” stuff in there as a kind of option for ppl who wanted to ignore zero cadence as a legit reading while they were cycling, as I saw a few ppl discussing how they didn’t like coasting messing up their averages.

I didn’t really want to make it a default, but I didn’t want to make it a parameter (I may not have had optional parameters at the time), and I couldn’t think of a short way to say “average excluding zeros”. AVGNOT0?

I looked at Excel and I think they use AVGIF with a conditional, although of course there’s other ways to do that in AppBuilder.

I guess with AppBuilder 5 you could type
AVG(ALT(Power, null))
to ignore zeros (assuming I changed what AVG does) but that isn’t exactly intuitive either.

That’s the main problem — none of this stuff is exactly intuitive or as simple as even JavaScript (on the surface). It’s more like Excel, Mathematica or Matlab, except worse.

It’s not like AppBuilder has even 10,000 users (and AppBuilder 5 barely has 100 downloads). Maybe I should change it for 5.

Update 5.8

BREAKING CHANGE

I ripped the bandaid off and removed AVG0, TIMEAVG0, LAPAVG0. All the average functions now consider zeros.

To ignore zeros in an average, use the new NONZERO(X) function (*), which returns NULL if X is zero, X otherwise.
e.g. Average cadence, not including zeros:
avg(nonzero(cadence))

(*) Shamelessly ripped off from Matlab.

I apologize to anyone who has to change their formulas, but AVG0 never made any sense, not even to me. This is one of the reasons I made AppBuilder 5, after all.

Update: AppBuilder 5+ [beta]

Big news if you own a D2 Charlie/Delta, Descent MK1, Fenix 5X, Fenix 5S Plus, Fenix 5X Plus, or 645 Music:

AppBuilder 5+ has been submitted to the store. You get a 4 or 6 field fullscreen layout with 6 formulas, all of which can be recorded to FIT. See attached pic below.

It should be approved in 3 days or so, and will be available here:
https://apps.garmin.com/en-US/apps/394941a6-4e73-4843-820b-fdcfbc877f3a

Current limitations:
- There's only one profile
- Labels are static, not based on formulas -- this could change in the future
- There's currently two layouts: four and six fields
- Text colour is fixed

Added bonuses over AppBuilder 5:
- Many more characters are supported in the larger "numerical font". You can use any of the following characters, plus spaces, without automatically getting a smaller font:
#%+-./0123456789:°


Other than the fact it's six fields, everything else works just like AppBuilder 5.

Disclaimer: I can only test in the simulator and not IRL because I don't own any of those watches....

---

Update 5.9 [CIQ2]

- Make app slightly smaller.
- Add LASTLAP[X] function
Captures the value of X at the end of the last lap.

e.g. [Replace square brackets with round brackets]
Last lap time: LASTLAP[LapTime]
Last lap total time: LASTLAP[Timer]
Last lap average HR: LASTLAP[LAPAVG

---

]

- Fix bug where joining text to NULL could make the whole string disappear

---

Update
AppBuilder 5: 5.9.1
AppBuilder Classic: 2.7.5

FIT recording - set internal FIT field label to "AppB:YOURLABEL". Not visible in Garmin Connect, but available in original FIT file.community.garmin.com/.../1429226.png

hotdogpartysausage Hey sorry about that. Yeah, sometimes I have a problem with rapid updates.... At one point I thought this app was dead in the water, so it was kinda fun to see the different ways it could be improved. Also, I'm still kinda shocked that anyone wants to use it haha.

I did break TIMEAVG while I was optimizing a few things. The latest version in the store is fixed -- I tested your formula and it doesn't crash anymore.

I'll probably hit pause for a few days unless there's any other bugs.

Hi Thanks for the speedy fix. It seems to be working again.

Given its flexibility I'm surprised more users aren't using the App. Maybe it just appeals to my inner geek that I like tinkering with the features.

One thing I was pondering, when you resume from your pause on development again. With the Edge 1030 being cycling specific it only has a Cycling sport type therefore doesn't have the ability to auto switch formulas based on the sport types defined in the settings. I was wondering if there was any way to leverage the sub-sport category ie Road, Cyclocross, Indoor etc or Activity Profile name to provide the same auto switch functionality?

hotdogpartysausage No worries!

I'm not surprised, TBH. People don't want complexity and flexibility, they want something that just does what they want. I have an app that literally took 5 minutes to develop which subtracts Total Descent from Total Ascent and it has more downloads than AppBuilder. It took me longer to find and edit a listing icon then it did to code that app. It does what people want. I'm sure people would rather download an app that lets them view Power in a running activity, instead of downloading AppBuilder and typing "Power" or "AVG[Power]" into settings. I'm sure I would. If I created a couple of apps that just display Average Power or Lap Average Power, Stryd would instantly start recommending those apps over AppBuilder.

But then again, as I pointed out to someone else, I have over 100 examples on the AppBuilder website. There's no way anyone is gonna release a separate app for each example, although sometimes it seems that way when you look at the CIQ store.

The problem is that there's a very narrow range of people who:
- Have a running/cycling problem they can solve with math that's simple enough for AppBuilder
- Know what math they want to use
- Don't want to code an app
- Can't find an existing app on the store
- Willing to learn a whole new "language" just to solve this problem

I mean, at what point is using AppBuilder just as hard as coding the app yourself, or even better, just asking someone else to make a real app that does what you want? Then you don't have to worry about AppBuilder crashing because the formula is too complex or the dev broke something.

I really just created AppBuilder to challenge myself - wasn't really expecting 600k downloads like dwMap. TBH I don't use it myself, because CIQ slots are at premium on watches.

Sorry, what you're asking for is impossible. The way it works is that the "sport type" is really the "HR zone" profile provided by the Connect IQ API. Garmin devices only support those profiles (running, cycling, swimming and other). Also, if your watch doesn't support those extra zone profiles, then the "sport auto-detect" won't work.

So I guess you'll have to suffer through the "hotkey" config switch method if you want to switch formulas >_>.

I think you're right with that synopsis. I think a lot of users like someone else to do the work, maybe its that they feel that they lack the aptitude others maybe not too interested in having a go. I'm a bit of a halfway house as I spend most of my working day looking a code in one form or another & sitting down in the evening and trying to make the transition into learning Monkey C was proving quite difficult to get my head around
That's what I like about AppBuilder; A lot of the background nuts & bolts work has been done by yourself giving the end user something that's flexible and highly configurable but using a quite simplistic structure with understandable & meaningful commands. I'm interested to see the direction of any future developments.

Thanks for the explanation of how you determine the sport type for the formula switching. I didn't know how much information was available in the API. I knew the sub sport information was written to the FIT file on saving the activity & the default setting is configurable in the activity profile on the Edge 1030. I just didn't know if that information was available at run-time.

Hey Ho Hotkeys it is then :rolleyes:

Something I've thought of as well. There will never be mass appeal for this kind of stuff. People want minimum effort easy solutions. Another good example is the DIY datafield which I also use, only 2k downloads. IMO these are two of the best apps around currently and inspire user creativity and new ideas, yet something like beers earned is more downloaded.

I've thought several times of looking at coding a data fields myself, but it's just that with long work days and family with 3 kids never got to round to it. Even playing around with these apps and testing eats time and then I have to find time to work out too.

Anyway thanks for the efforts and putting this available to few of us willing to spend some effort to make use out of it. Much appreciated. :)

JTH9 hotdogpartysausage No worries. Glad you're finding it useful.

I think the apps with the most appeal are either watchfaces, or apps like dwMap which give you legit useful features that are only available on much more expensive watches. Then there's the single run fields, but everyone has one of those now.

Well, the irony is that AppBuilder can really only be "enjoyed"/appreciated by people like us who can already code. And if you can already code, then you can already make your own app. AppBuilder really only removes the friction of installing Eclipse, learning Monkey C and submitting your app to the store. That's probably why there are so many apps which just calculate 3s Power or whatever. Because it's something simple that people need, or it's something simple that the dev themselves wanted. Even if only 5 to 50 people downloaded some obscure app that calculated Calories / TE or something, it's probably more useful in a very real way than AppBuilder. The dev decided what information was useful to display, and they tested the app to make sure it will display the right information and never crash (haha I know, right?)

I do see a couple of advantages to AppBuilder that unfortunately aren't enough:
- You can display selected activity info in sports that normally hide it: Power in Running, Lap Count during strength training. Someone asked for an app that shows their set count during strength training, because Garmin doesn't show it. So I told them to use "lapcount div 2 + 1". Is it worth it for anyone to make a whole app just to display that? Who knows. That's what would normally have been done.
- You can change your "app" fairly quickly without recompiling, resubmitting and/or adding new settings. Unfortunately the various options for changing settings for GC apps aren't really well suited for this, either, especially with how GC automatically leaves the settings page when the watch syncs.

I was talking to a friend about this: for AppBuilder to be truly successful, it would have to be like Siri:

"Show me running power"
"I want to see 3-second Pace"
'What's my FTP?"

A lot of times people downloaded AppBuilder and just asked me what formula to use, which one step removed from that idea. Which is fine, but apps should be about empowering people, and ironically, the best way to do that is to do the thinking for them. I understand completely, because I don't download apps so I can do a lot of thinking and work either. Apple became very successful in large part by making lots of decisions for the end user, even when a vocal minority (or even majority) initially hated them.

Anyway, the fact that I don't use it myself probably says something. If I had a watch that could display the full page version, maybe I would, but probably still not. My favourite apps happen to be dwMap and Dozen Run, although I don't need dwMap anymore. The dev of Dozen Run already decided what information to show the user. There's a handful of options, but in the end, the dev made a bunch of decisions for the user, instead of forcing the user to do all that work.