Есть список композиций. Заранее неизвестно будут ли найдены файлы для них или нет. Запросы в сервисы отправляются параллельно.

Воспроизведение начнётся сразу если найден лучший вариант из возможных, либо когда все запросы выполнятся

Пользователь может поменять предпочнения относительно источника файлов, изменения применятся мгновенно в том числе для текущего процесса поиска

После завершения поиска в одном из сервисов для текущей композиции будет запущен поиск для следующей

Если файлов нет, то поиск пойдёт до следующей и так далее пока не кончится список или не будет найдена композиция с файлами

Это будет происходить во время воспроизведения текущей композиции, чтобы воспроизведение списка было непрерывным

Вконтакте сразу не доступно, но если пользователь залогинется, то будет сразу добавлен новый источник поиска и туда будет отправлен запрос

Этот запрос тоже будет учтён при принятии решения о том когда воспроизводить.

Файлы могут быть недоспутны по ссылкам что дали сервисы. Если все файлы оказались недоступны, то и композиция помечается соответствующим образом

При всём перечисленном вы можете пользоваться навигацией в приложении.

Одно дело собрать все эти данные и выплюнуть пользователю или конечному разработчику, после чего забыть про этот ответ. Другое дело собирать по кусочками, давать взаимодействовать, влиять на конечный результат, и следить чтобы «счётчик сообщений™» показывал правильное число.

Как я это всё разруливаю? Никак. Я указываю зависимости между состояниями, между моделями, а феймворк разруливает это за меня

Указываю зависимости, а фреймворк следит за изменениями, актуализирует, точечно обновляет

Про торренты.

Допустем у нас есть поисковик торрентов или база рутрекера.

Мы отправляем запрос, получаем infoHash торрента. По сути id.

Отправляем запрос в dht и по кусочкам получаем список файлов и информацию как их получать.

Из файлов выбираем то что мы хотим получить и скачиванием, воспроизводя.