continuous seek interval should not be hardcoded

[nt4f04uNd]

Is your feature request related to a problem? Please describe. https://github.com/ryanheise/audio_service/blob/ea0318cb16c0abbe3b83eed1ed99fabf06609ff0/audio_service/lib/audio_service.dart#L2553-L2559

Describe the solution you'd like as this is not required on native side, it could be an overridable getter in SeekHandler

Describe alternatives you've considered none

Additional context no

[ryanheise]

It's been a while since I looked at the mixin semantics. What happens if you override seekForward and seekBackward in your handler to do nothing? Does the mixin end up overriding that?

[nt4f04uNd]

mixin is added as super and you can reference it as super and override its methods and fields

[ryanheise]

That's good, I was momentarily worried about nothing.

Regarding your proposal, are you suggesting something like this?

mixin SeekHandler on BaseAudioHandler {
  ...
  Duration get continuousSeekForwardInterval => Duration(seconds: 10);
  Duration get continuousSeekBackwardInterval => Duration(seconds: 10);
}

[nt4f04uNd]

yes

[ryanheise]

Also should probably do the same to configure the frequency of the jumps which is currently hardcoded to happen every second. Although you didn't specifically request this, would you have a preference over having a single setting for both the forward/backward directions or having the directions separately configurable? I personally can't imagine why someone might have a different frequency in each direction.

[nt4f04uNd]

speaking of that, i would rather expose the Seeker for broader configurations

(we can still have these two getters continuousSeekForwardInterval and continuousSeekBackwardInterval, but not pass them not as parameters to Seeker, just to have seeker calling them)

  Duration get continuousSeekForwardInterval => Duration(seconds: 10);
  Duration get continuousSeekBackwardInterval => Duration(seconds: 10);

to come up with better concept, i would need some additional time, but i guess you can infer it from such use case:

• like in windows TV & Movie app i have such intervals
• i would like to have an exponential seeking in both directions (i would achieve that with extending Seeker as ExponentialSeeker)
• the more greater the seek position interval becomes, the greater stepInterval grows, because intial intervals are different in each direction, they grow differently

to summarize, i wouldn't have getters from step intervals by default, but would expose the Seeker for that

[nt4f04uNd]

however, the use case i provided is quite rare and easy to implement by just looking at the source code, so i rather think this should not be added

[ryanheise]

Thinking about this more, maybe it is better that I implement this feature (along with customisability) in just_audio.

[nt4f04uNd]

will the SeekHandler still be that valuable then? if we do that and not remove it, we would have to either force users to use either it, or utils from just_audio, or we would have to introduce a circular dependency

[ryanheise]

A just_audio-based handler wouldn't need SeekHandler but I suppose it could still be provided since it may be useful in other implementations.

[nt4f04uNd]

i agree these utils better suit just_audio, but audio_service needs them as well

[nt4f04uNd]

A just_audio-based handler wouldn't need SeekHandler but I suppose it could still be provided since it may be useful in other implementations.

ok then