by L Schmidt
It's not uncommon that mobile devices are used for navigation on motorbikes, attached to the steering bar or put in a tank bag sleeve, though interaction becomes a bit of a problem, especially with gloves on. A solution is a Bluetooth media controller, which are available cheaply, and provide a small set of media keys, often 5, which can be attached to the steering bar and used to control the mobile device.
Those keys are usually:
Some of those buttons may provide a secondary function, by long pushing.
Here's a flow which intercepts some of these buttons, and maps functions convenient for use on motorbikes. Depending on preferences and controller, you may need to customize the flow. This configuration meets my requirements and controller.
Previous track, next track:
The flow reads a text file with name specified in variable "applist". This file contains package names, one per line, of apps to round robin switch between them.
Next track switches to next app, previous track to previous app in that list.
My entries to that list are navigation apps, speedometer, driving style recorder/analyser, weather forecast and fuel prices of nearby gas stations. I currently have seven apps in that list, tendency changing because the list is easy to modify using a text editor.
It's now checked that apps in that list actually exist, as the flow aborted with an error in case an app didn't exist in previous versions. It also aborted when encountering an empty line (like, a new line at file end). Such cases are now logged.
Volume up, volume down:
Not intercepted, because the nav apps I'm using handle these keys already, by zooming into and out of the map.
Volume keys up, down, long push:
Starts the speed cam/radar trap warning app, then backgrounds it.
restarts round robin app switch loop, i.e. jumps to first app.
These speed cam/radar trap aspects of the last two keys are dummied out in this flow by toasts, as you may need to customize the launch and kill sequences. Example actions for the Blitzer.de plus app are provided, but unconnected.
The kill action is also performed on my device when power is cut (I.e. ignition turned off)
Long pushing of previous track on my controller causes the screen of my mobile device to turn on or off, no flow action needed for this, therefore no keys intercepted.
Next functional addition will probably a function, mapped to a key, which will record coordinates, then start audio capture over Bluetooth, meant to aid correction of OSM tags. That has been added to my personalized version of this flow, looking like this:
Preliminary stand-alone version of such a flow is here:
The controller I use is a device purchased at aliexpress for about 4€. I took care of choosing one with prominent keys, as those are easier to operate with gloves donned.