Ticket Created
over 5 years ago

WERETECH-7661

WERETECH-7662

WERETECH-7663

WERETECH-7853

WERETECH-7854

Assorted Media Player Button Bugs Across Devices

I've been experimenting with some of the media player button handling code across different devices and run into a few issues. Below is a table which summarizes my findings.

For context, Runcasts currently implements fast-forward/rewind using some pretty crazy hacks which re-map the skip-previous / skip-next buttons into changing the ActiveContent playhead. Needless to say, I'd love to strip that code out and use the normal approach. Unfortunately, the various options below all suffer some drawback on one of the devices we're trying to support.

Feature Vivoactive3 Button-Based Button-Based Hotkey
SystemButton BUG [1] OK OK
CustomButton OK OK BUG [2]
PLAYBACK_CONTROL_SKIP_BACKWARD/FORWARD BUG [3] OK [4] OK
  1. Image doesn't show, button doesn't work              
  2. Image shows, button event doesn't fire when clicked                    
  3. Crashes, no CIQ.YML generated
  4. Not a bug per-se, but a record-scratch occurs during skip, hacks to implement fast-forward/rewind avoid the record-scratch sound (at the expense of being slightly delayed when starting) 

rconradharris
Parents
  • over 5 years ago

    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.
Comment
  • over 5 years ago

    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.
Children
  • over 5 years ago in reply to rconradharris

    Hello, can you explain => "

    • Media.setPlaybackPosition(int) -> you can achieve this using ContentIterator.get and ActiveContent, but its pretty cumbersome for such a simple and common task."

    I try to start a music at a position but I can't, I must use ActiveContent badly because it tells me that mMetadata is null.

    Thank you in advance for your assistance