Adding a way to disable items in the queue

[delannoyk]

This PR is an implementation of what is discussed in #61. The goal here is to define at runtime - and before an item is played - if an AudioItem should be played or not.

This allows the original request to disable remote items when WiFi connection is down, but also allows other use cases.

Here's the todo list:

• Added a delegate method to check if an item is playable or not
• Use that method in AudioItemQueue to return the correct values in nextItem(), hasNextItem, previousItem() and hasPreviousItem.
• Verify the implementation with new unit tests.

[delannoykbot]

Danger has errored

[!] Invalid Dangerfile file: undefined local variable or method xcov for #<Danger::Dangerfile:0x00007fbf77c36d18>

 #  from Dangerfile:20
 #  -------------------------------------------
 #  # Asserts the test coverage meets the threshold
 >  xcov.report(scheme: 'AudioPlayer iOS', project: 'AudioPlayer/AudioPlayer.xcodeproj', minimum_coverage_percentage: 50)
 #  -------------------------------------------

Generated by 🚫 Danger

[delannoyk]

Documentation warnings are false positives (see this).

Anyway, there are still some concerns about the implementation I'd like to address:

• What happens if the queue mode is .repeat? Should it still go to previous/next item in the queue? I think the player should fail with a new type of AudioPlayerError, something like .itemNotConsideredPlayable.
• What happens when the entire queue is considered unplayable? I also think a new error should be added .noItemsConsiredPlayable.

What do guys think of this?

[codecov-io]

Codecov Report

Merging #76 into master will decrease coverage by 20.03%.
The diff coverage is 15.51%.

@@             Coverage Diff             @@
##           master      #76       +/-   ##
===========================================
- Coverage   75.72%   55.68%   -20.04%     
===========================================
  Files          39       25       -14     
  Lines        2797     1406     -1391     
===========================================
- Hits         2118      783     -1335     
+ Misses        679      623       -56

Impacted Files	Coverage Δ
...ioPlayer/AudioPlayer/player/AudioPlayerState.swift	100% <ø> (ø)	⬆️
...Player/player/extensions/AudioPlayer+Control.swift	9.09% <0%> (-0.53%)	⬇️
...ioPlayer/player/extensions/AudioPlayer+Queue.swift	0% <0%> (ø)	⬆️
...layer/AudioPlayer/player/AudioPlayerDelegate.swift	0% <0%> (ø)	⬆️
AudioPlayer/AudioPlayer/item/AudioItemQueue.swift	97.14% <75%> (-2.86%)	⬇️
...er/player/extensions/AudioPlayer+PlayerEvent.swift	24.77% <0%> (-11.89%)	⬇️
...yer/AudioPlayer/event/AudioItemEventProducer.swift	86.84% <0%> (-10.53%)	⬇️
...ioPlayer/AudioPlayer/event/SeekEventProducer.swift	86.84% <0%> (-10.53%)	⬇️
...oPlayer/AudioPlayer/event/RetryEventProducer.swift	89.58% <0%> (-8.34%)	⬇️
...r/AudioPlayer/utils/CMTime+TimeIntervalValue.swift	91.66% <0%> (-8.34%)	⬇️
... and 23 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1717403...d4a6549. Read the comment docs.

[jadsonlourenco]

"What happens if the queue mode is .repeat?" Should play the first item of playlist, no?

[delannoyk]

@jadsonlourenco I kind of changed my mind implementing it and went for a repeat mode that doesn't account for the current "availability" of the current item.
So if the queue is in repeat mode, it will keep trying to play the same item over and over again. I think that's a pretty fair behavior. What do you think?

[jadsonlourenco]

Yes, and .repeatAll should repeat all the current items again, from beginning (but, with shuffle?).

[delannoyk]

@jadsonlourenco Yep.

Shuffle will just play the shuffled queue and skip "unavailable" items.