audio_service и just_audio дизайн для приложения, поддерживающего очереди и несколько списков воспроизведения

Я создаю мобильное приложение для Koel, используя Flutter и комбинацию +. Приложение в основном работает так:

  1. Пользователь входит в систему
  2. Приложение загружает большой объем данных JSON с сервера.
  3. Приложение анализирует указанные данные по песням, исполнителям, альбомам и плейлистам.
  4. Приложение позволяет пользователю добавлять песни (вверху / внизу / после текущего) / удалять песни из очереди и воспроизводить или перемешивать их. Во всем приложении есть только одна очередь (т. Е. Если пользователь нажимает «Воспроизвести все» на экране списка воспроизведения, текущее содержимое очереди будет заменено песнями из этого списка воспроизведения).
  5. Я предполагаю, что очередь ( List<Song>?) и всегда должен быть (хотя и может быть пустым), чтобы можно было выполнить шаг 4

Я пытался реализовать шаг 4 и далее с помощью and (), но пока не так успешно. По сути, мне непонятно, как спроектировать архитектуру приложения. Нужно ли мне инструментировать очередь и синхронизировать ее с и just_audio, и если да, то как? Когда пользователь удаляет виджет песни из пользовательского интерфейса, как мне удалить соответствующий виджет из очереди и из ConcatenatingAudioSource? Что пользователь нажимает «Play Now» на виджете песни на экране списка воспроизведения, что должно произойти под капотом, чтобы игрок переключился на эту песню, сохраняя при этом очередь активной?

(Возможно, стоит упомянуть, что примеры, приведенные audio_serviceдовольно просты с фиксированным списком песен в фиксированной очереди, что вряд ли похоже на мой случай. Кроме того, некоторые функции (например, постановка песни в очередь после текущей), похоже, недоступны, что означает, что мне придется полагаться на BackgroundAudioTask.onCustomAction, который принимает в качестве аргументов только определенные типы данных . MediaItem и мой обычай Song объекты модели, похоже, не поддерживаются.)

Источник

1 ответ

Я согласен с вашим подходом к сохранению сингла ConcatenatingAudioSourceи просто используя свои методы для вставки, удаления или замены своих дочерних элементов. Затем вы можете прослушать, чтобы увидеть изменения в плейлисте just_audio и передать их в audio_service.

В этом ответе показано, как поддерживать синхронизацию плейлистов just_audio и audio_service с помощью предварительного просмотра грядущей версии 0.18 audio_service. Во-первых, сохраните MediaItem audio_service внутри объекта tag свойство каждого элемента в вашем плейлисте just_audio, затем сопоставьте и перенаправьте последовательность just_audio из sequenceStateStream в очередь audio_service:

      _player.sequenceStateStream
    .map((state) => state?.effectiveSequence)
    .distinct()
    .map((sequence) =>
        sequence?.map((source) => source.tag as MediaItem).toList())
    .pipe(queue); // <-- this is the audio_service queue stream

Если вместо этого вы используете audio_service 0.17 или более ранней версии, принцип остается таким же на стороне just_audio, за исключением того, что на стороне audio_service есть setQueue метод вместо queuestream, поэтому вы не можете просто перенаправить поток. Вместо этого вы удалите .pipe(queue) укусить в конце и сделать .listen(AudioServiceBackground.setQueue).

Эффект состоит в том, что каждый раз эффективный плейлист в just_audio изменения (т.е. список воспроизведения), он будет транслировать новую очередь в audio_service.

Источник
Другие вопросы по тегам