Assorted Media Player Button Bugs Across Devices

Jarrod.ConnectIQ Sure thing!

On the button-based watches, the first control returned from the `getPlaybackControls()` method is rendered on the player’s main/primary page along with the ‘Play’ button and the ‘Detail’ button (‘...’). The rest of the of the controls in the array are rendered on the secondary/detail page (the view that is pushed when you click ‘...’).

What’s interesting here is that if you set a `CustomButton` to the second element of the `getPlaybackControls()` array, everything works fine. The control renders properly, and the `onCustomButton` handler is called when the button is clicked. This is the non-hotkey configuration that works.

When you set the `CustomButton` as the first control (what I was calling ‘primary button’ but I think I heard Garmin folks calling it the ‘hotkey’), then something strange happens. The button renders just fine, however, when you go to click it, nothing happens. It looks like, for some reason, the `onCustomButton` handler isn’t being called. This is the non-working hotkey configuration.

 rconradharris, on Bug 2, could you clarify what 'Button Based Hotkey' is referring to? Is it holding 'Down' to access the music player?

I'm attempting to reproduce this, but I'm not seeing it, so I may be missing something. If you were able to provide any specific steps to reproduce, that would be super helpful.

Along with BUG [4], I should probably include a BUG [5] as well:

While PLAYBACK_CONTROL_SKIP_BACKWARD/FORWARD works on button-based watches, it leads to a fundamental problem: once it has been triggered, there is no way for an app to know its current playhead position!

There isn't an API to interrogate the system for current playhead position (feature request :-), and there isn't a corresponding SONG_EVENT emitted so that we could figure this out ourselves. I *think* there might be an extremely hacky way to work around this, but I hesitate to even mention it here without confirming it does indeed work. Regardless, there probably should be a sensible way of determining this using system APIs.

Overall, the current APIs can be characterized as 'event-driven': the developer can't ask about the current state; instead they are forced to build those APIs themselves from onSongEvents. While this works, it's rather cumbersome since it requires the app to store the state themselves and create somewhat complex state machines within the onSongEvent handlers.

Adding the corresponding SONG_EVENT seems like the most harmonious thing to do, given the current design. But, additional APIs to ask for state, would go a long way to making things easier on developers.

A wishlist of new APIs would look like:

• Media.getPlaybackPosition(): return the current playhead position in seconds as a Number
• Media.stopPlayback(): stop the currently playing track (inverse of Media.startPlayback)
• Media.setPlaybackPosition(int) -> you can achieve this using ContentIterator.get and ActiveContent, but its pretty cumbersome for such a simple and common task.

Looks like BUG [2] still occurs on 3.1: I just tried it on the latest 645 M FW (5.90) which says that it's CIQ 3.1.

for BUG[2] is that on a device with a 3.0 VM or 3.1VM?  There's the 8.02 FW for the f5+ devices with a 3.1 VM, and I wonder if that might have been fixed in 3.1