A modest proposal, or let us script

This is not a pie in the sky feature request dump but rather a series of examples of things I've seen requested and upvoted, or thought of myself, and believe could be achieved (or at least "functioning prototype"-d) by the community, with minimal work done by Hammerhead. Some of it may be tricky to understand for non-developers.

It's basically things that already exist, plus a tiny bit of Unix glue. Sorry if it's a bit long-winded and repetitive, couldn't find the time to write something shorter.

First, single width graphical fields (as previously planned but then bumped due to battery drain - I don't mind battery drain, I have a power bank.) It should be my choice, simply warn the user of the impact. This, combined with actually opening up usage of your so-called "public SDK" up on GitHub should bring lots of features many people have asked for such as colored fields/background color in fields depending on type, zone etc, as well as pack more information in.

The SDK has been up since beginning of the year but apparently still won't run on prod devices. When will this change? I have an idea for an open source app I intend to start building (and hopefully eventually get on your app store?) that will merely feed arbitrarily set up custom fields massaged data from whatever sources - initially just stdout, text files and existing ride metrics but then also hopefully device sensors, connected sensors, sockets, idunno. This, data sourced from small sharable shell or py or node or whatever scripts (whether on cron or executed by the app, with args, in response to something), or, for advanced things we'll get to below, Automate flows or similar, to fetch and process data, could easily incorporate a lot of requested functionality without HH having to build it. ...or app be specifically pre-programmed for it, or using intents (vis a vis core Karoo apps) or whatever. I'm not an Android dev (which is one of the reasons app itself should do as little as possible, just act as a trigger and collector really) so too aware of greater possibilities and difficulties.

Permissions would only be needed for app itself I suppose, so no rogue scripts wrecking havoc.

Some examples are weather forecast and live wind speed, heading, custom historical graphs (like for power and HR), n seconds of smoothing for any metric (maybe wouldn't want to run too much stuff requiring constant updates though), crappy HR calorie estimates people won't shut up about needing, data provided by sensors but lacking a field to display it like HRV or pressure.

You could call the approach hacky and it is, but hey, if it works for tmux... Ideally there'd be a repository for such scripts and their corresponding basic field presentation settings, accessible from the app and vetted by the community.

Since the vast majority of users wouldn't write their own scripts but use published ones, tracking this usage would also help you gather some data on what people actually want, and help you focus on then properly building what's most popular in practice (which should still be done for sake of efficiency, accessibility etc) and knowing what can safely be deferred or ignored. Hell, you might use it yourselves to prototype stuff. Or better yet you've already thought of all this and have just such an internal app already in use (given recompile-deploy while iterating is for suckers, sayeth I, while hiding in my JVM lisp REPL that takes several minutes to boot), and which you will grant us any day now.

But I digress.

There's one more thing.

Make all fields actionable! Should be simple enough given there already are fields that take input. Further down the road it'd be nice if tapping a field would bring up a drawer for that specific metric (so, tap a power field, get all the various 3s 10s 30s etc as well as NP and more). This would of course involve significant development time (unless you also expose a public API for building drawers... hint hint), but in the meantime simply sending a signal to the app whose field it is would make a lot of things possible.

-Triggering custom pre-set countdown timers (which could, apart from count down things for you, also result in actions, such as auto laps and auto scrolling pages, which I know are two common requests)

-Cycling what a certain field is to display or how it displays it or smoothes it, much like switching pages.

-Quickly switching map from 4 field to 2 field by just sending commands resulting in going back to main screen and selecting another profile.

-If doing separate signals for touch-down and touch-up could do a hacky version of drawer idea where if I'm on my main screen and touch a power field it'll swipe to jump three pages right to my all-power screen, then return once I let go.

-Setting up a custom trainer control page with a field displaying current ERG wattage and "button fields" to adjust it up and down, and perhaps further fields to jump to preset levels (though I suppose this would require either app speaking ANT directly, access to send such commands through an API, automating a trip into Sensor app and subsequent taps, or altering and reloading a custom workout file on the fly, hmm)

I already have a bunch of automations akin to some of those above set up, but the lack of integration/context awareness and having to fiddle with tiny floating buttons or memorizing gestures makes it too messy. There are already ways to do it properly by spying on UI elements and such, but the way the Ride app is designed (every page included in current view, most stuff simply offscreen) makes it quite tricky (and far too cumbersome setting up multiple things on the unit).

It'd be messy regardless, and also inconsistent, and confusing, absolutely terrible UX really... but hey it'd all be adults opting in, and patterns would emerge.

It should be obvious by now it's quite tricky for HH to develop this product at the speed many people are asking and hoping for, working alone and still having to focus on core stability. But you don't have to! The platform you have chosen is ideal for others to join in, and you've even set things up for that, single-app app store, repos and all.

Now the time has come to leverage Android (or initially at least its Linux underpinnings). Leverage APIs. Leverage us hackers, tinkerers, developers. I'm sure I'm not the only one here.

You will still build your vision, but niche users willing to accept some tradeoffs won't have to wait for you to get to their favorite item 238 on the agenda. Nor even wait for an Android dev to build feature x into their custom field app. Device-agnostic scripting knowledge will be all that's needed to create a whole bunch of custom data stuff, and existing fairly easy to use Android automation apps used for advanced - reasonably aware and integrated - control.

Wouldn't that be grand?

tldr; let us write apps already, let app know if its custom field is tapped, I reckon we can script and glue the rest.