-
Notifications
You must be signed in to change notification settings - Fork 741
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Voice Message Playback Scrolling Support #5404
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor remark.
Static review OK!
It should deserve some manual test though.
@@ -69,6 +83,8 @@ class VoiceMessageViews( | |||
observeMicButton(actions) | |||
} | |||
|
|||
private fun getTouchedPositionPercentage(motionEvent: MotionEvent, view: View) = motionEvent.x / view.width |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not tested, but show probably use coerceIn(0,1)
to avoid overflow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More secure, done.
@@ -695,8 +709,7 @@ class MessageItemFactory @Inject constructor( | |||
return this | |||
?.filterNotNull() | |||
?.map { | |||
// Value comes from AudioRecordView.maxReportableAmp, and 1024 is the max value in the Matrix spec |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment is still valuable, no? Maybe just update the part about AudioRecordView.maxReportableAmp
to AudioWaveformView.MAX_FFT
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, done.
@@ -0,0 +1,22 @@ | |||
<?xml version="1.0" encoding="utf-8"?> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file should be moved to https://github.com/vector-im/element-android/tree/main/library/ui-styles/src/main/res/values
and its name should start with stylable_
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
when scrubbing the play head, should the audio continue to play? at the moment we're pausing each time we change the play head position 🤔 |
mediaPlayer?.stop() | ||
stopPlaybackTicker() | ||
} | ||
|
||
fun movePlaybackTo(id: String, percentage: Float, totalDuration: Int) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we use the mediaPlayer?.duration
then we'll be able to avoid inferring the duration from the UI countdown ticker
would that be possible? (it would assume the media player is in the prepared state)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have a single mediaplayer which is initialized when users start the playback. But users are able to scroll idle recordings and the mediaplayer is null at this stage.
is VoiceMessagePlaybackTracker.Listener.State.Idle -> renderIdleState(holder) | ||
is VoiceMessagePlaybackTracker.Listener.State.Playing -> renderPlayingState(holder, state) | ||
is VoiceMessagePlaybackTracker.Listener.State.Paused -> renderPausedState(holder, state) | ||
// Don't track and don't try to update UI before view is present |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this because we're relying on holder.voicePlaybackWaveform.post
? if so we should move the tracker logic to the same post
body to better couple the logic together (it seems that we're relying on the audio view to be fully drawn because it only updates its internal state as a side effect of the drawing)
actually... do we need any of the posting? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes we need post
because the width of the view is 0 (not calculated yet) when it is bind. Do you mean holder.voicePlaybackWaveform.setOnTouchListener
should be inside post block?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it might be safer to rely on viewWithLateWidth.doOnPreDraw { }
or doOnLayout { }
if we need the width/height at some point~
for the moving I meant moving the tracker calls to be inside the same holder.voicePlaybackWaveform.post
as the comment suggests the view doesn't exist yet but they should be inflated at the same time as the parent 🤔 so I'm assuming the lack of data inside the voicePlaybackWaveform
is causing trouble, which would be fixed by moving the tracker into the same post
block 🤞 If I've understood correctly!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for clarification! Done, if I understood you correctly.
Ideally yes, I couldn't find an easy way to implement it and I am not sure this is a blocker. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the update! 💯
@onurays the Player visual events freeze for me after skip play and stop a Voice Message and play a another one above the timeline. |
* develop: (429 commits) fixing the onboarding sanity test failing - adds tapping the new take me home button within the sanity test Fix lint issues on weblate sync fixing view model tests not collecting flow results - the switch from runBlockingTest to runTest means we need to provide a separate scope from the test in order to asynchronously collect the flow results Do not suggest collapse if there is only one section Translated using Weblate (Spanish) Translated using Weblate (Spanish) runBlocking -> runTest https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-test/MIGRATION.md runBlockingTest -> runTest https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-test/MIGRATION.md Small cleanup The `.exhaustive` trick is not needed anymore in Kotlin 1.6.0 https://kotlinlang.org/docs/whatsnew16.html#stable-exhaustive-when-statements-for-enum-sealed-and-boolean-subjects Also upgrade the coroutine lib Fix compilation warning (exhaustive when) Fix compilation warning (exhaustive when) Format file (no other change) Fix compilation warning (exhaustive when) Bump moshi from 1.12.0 to 1.13.0 Bump kotlin-gradle-plugin from 1.5.31 to 1.6.0 fixing presence icon anchoring to the middle of the room icon - creates a secondary verification shield and aligns to the start of the room title when presence is present PR remarks Increase the thread summaries limit ... # Conflicts: # vector/src/main/java/im/vector/app/features/home/room/detail/composer/voice/VoiceMessageRecorderView.kt # vector/src/main/java/im/vector/app/features/home/room/detail/timeline/item/MessageVoiceItem.kt
Good catch, thank you. I will fix this in another PR. |
Fixes #5426.
vm_scrollbar.mp4
Voice Message related UI and state classes became to be messy. We should plan to refactor them by rethinking all states and flow between them.