Hi everyone! Saturday Keunes, ByteHamste and I meet and decided the beginning of a deep mapping of all changes needed to be done in order to implement Multiple Queues on AntennaPod.
So here we will begin to list the Features impacted by Multiple Queues or New Features/Behaviors needed to be considered for implementation. Disclaimer: We are going to begin the implementation by adding simple and “dumb” queues that need somehow have the be manually managed by the user.
In general, today AntennaPod expects the existence of an unique queue, all features based on this unique queue need to be changed to expect the existence of multiples queues and so, we need a rule to decide which queue to use.
I will start listing here what are those features that I have detected until now.
A brief context about my personal implementation: I have created the capability for queue creation, where all queues having a name. I have kept a default queue, so I didn’t touched any current behavior of AntennaPod regarding to queue. All failures on identifying a queue, fallback to the default queue usage. Even so, I have some unexpected bugs. I have created multiple queues in order to be able to specify a automatic/smart queue, so I don’t really use multiples queues, considering that, I haven’t explored all, if any, aspects of multiple queues. I don’t consider my fork code to be directly used for the final implementation. I will use it only as a reference to implement multiples queues from the scratch on a clean branch.
Queue Attributes: All queue should have a name specified by the user and an id for AntennaPod work with it. In case of a default queue should it have a name modifiable by the user? Where to place the feature to do Queue renaming? Are there any other attributes?
Queue creation: Today we have a default and unique queue. Should AntennaPod expect the existence of a default queue? So if the user don’t create any additional queue, all the existent behavior should be preserved. This way the Multiple Queue feature would be added without changing the usage complexity for current users that don’t feel this need. Where should be placed the commando for queue creation? Should it be able to create queues from the queue screen menu? If we start without any queue, should we automatically create one once users begin adding Podcasts? Should this first queue creation be transparent or explicitly to the user? Note: If we choose to keep a default queue we could cold install AntennaPod with this queue.
Queue deletion: Where to place the command for queue deletion? Once a queue is deleted, what to do with the play items added only to it? Should they be deleted? Should the user to be prompted to choose between the deletion or to move to another queue? Should user be prevented to delete all queues? So if the user try to delete the last existent queue, should we block the action and suggest the user to clear the queue instead?
Drawer Menu: Needed the definition if we will show the Queues directly in the drawer or just change the item name to indicated that now we are talking about QueueS instead of Queue. In case of listing all queues from the drawer, we need to specify what to list on a clean install (see queue creation). If we list the queues on the drawer should we show how many items there are for each list?
The Queue screen: Should it have a switch capability for changing between queues or should exists a intermediate screen listing all queues to be accessed by the user. In the case of a screen with switching capabilities, what is the rule to define the queue to be opened by default? Should it be the last used by the user? If the drawer has the capability to list the queues, it should send the parameter to the queue screen to open the requested queue for listing
Playback state: Today AntennaPod store its playback state without queue information. It should now begin to store this information to resume from the previous queue used by the user.
Android Notification Panel Item: Should we show the current queue for the user? Should we provide a way to switch between queues from there?
Cover Screen: Should we display the current queue also on this screen? That seems to make sense for me, so user know from which queue that item is being played, that way the user know what to expect after it.
Android Auto: All Android Auto screens and layouts need to be changed to comply with multiple queues.
Episodes Screen: Today we show an icon that communicate to the user that a episode is queued. Should we show the queue name? In case of a episode be placed on multiple queues, what should be displayed?
Episode Queuing: Should user specify the queue destination for an episode once the user click it to download? In case of existence of an unique queue, should we fallback to this queue, without asking any action to the user? Or should we prompt it with an option for creating a new queue or use the existent one? Once a Podcast have automatic download enabled, which queue should be used for the downloaded episodes? Or should we keep them in the inbox for the user to choose a destination queue? Here we are beginning to deal with a kind of smart configured queues aspects. This aspects should be considered when user hold click on any episode and then select “Add to Queue”.
Queue sorting: We should keep the current behavior, but the code now need to know which queue is being sorted. I haven’t changed the sorting capabilities so any time any sorting algorithm is triggered AntennaPod does update the Queue table by moving everything to default queue.
Listened episode (and mark as played): What to do when user listen to an episode listed in more than one queue (or hold press over it and selects mark as played)? Should we remove and/or mark as played from all queues? Should we remove/mark only from the current queue? If so, the automatic deletion needs to be aware of how many queue holds reference to an episode.
Episode deletion/removal: The same as above needs to be considered when user holds a episode and choose “Delete” or “Remove from queue” from any screen.
Reset Playback position (or even the track of current playback position): Should it be done for every queue or globally? So if an item if half played on a queue and its reached on another queue, should we start over or should we resume it? This one will be a kind of polemic since it depends on what user wants from multiple queues.
Queue lock: The lock behavior should be enable/disable by queue. Today if I enable it, AntennaPod locks all queues.
Queue Swipe Actions: Should also be configured by queue or should it be configured globally? Personally I think it makes sense to be a global configuration.
This is everything that I have found for now, and also that I can remember from our meeting. If I remember anything else, I will add.
Ps.:
Automatic Queuing: This is for future implementation. Should user be able to ask a Podcast to be always queued in a certain queue? Should it be possible to specify more than one queue? Where to place this configuration? Should it be related to the Podcast or should it be the queue? Consider the delete cascading: Podcast deletion will cascade the deletion of this configuration. While Queue deletion will cascade to this configuration, leaving Podcast without the configuration. My current implementation use the second approach and I haven’t implemented any treatment for what happens when a queue is deleted and a Podcast and up without any queue configured to use it. There are many other aspects to be considered on automatic queue so we will not dive into it for now.
)
