Refresh button feature request

Support
1

Samsung galaxy S9 SM-G960F
android v10
Antennna Version 3.3.2

I would vote for having the refresh button back, either next to the search button or in place if it.
Could you make the choice if button configurable?

(Can I install the previous version to get it back?)

Many thanks for an otherwise great product.

John

App version: x.y.z (state whether from Google Play/F-Droid/Custom built APK)

Android version: 5.x (Please mention if you are using a custom rom!)

Device model:

Expected behaviour:

Current behaviour:

First occurred: (e.g. about x days/weeks ago)

Steps to reproduce:

  1. This
  2. Then that
  3. Then this
  4. Etc.

Environment: (Settings you have changed (e.g. Auto Download). ā€œUnusualā€ devices you use (e.g. Bluetooth headphones). Did you select another media player?)

2

Someone clued me in that I could start a refresh by sliding the screen down. Now I never use a button to start the refresh. Maybe the button was moved to a sub-menu because it isnā€™t normally needed?

3

With the influx of new users (Iā€™m assuming a chunk from the Google Podcasts shutdown) it would be cool if there was a way to basically heat map usage of specific buttons, etc. to see what feature requests make sense to implement based on actual usage by a majority of users.

4

That would mean we would have to track users. We currently try to be as privacy friendly as possible

5

Understood. I figured Iā€™d ask so I could get an ā€œofficialā€ response but assumed that might be the exact reason it hasnā€™t been discussed before now. :slight_smile:

Have you guys ever considered some sort of ā€œvotingā€ capability here on the forums then to see what type of user interest/feedback there is for feature requests?

1 Like
6

As one of those Google Podcasts refugees I do recognize how it would help to see which AntennaPod features are used and how. That said, I appreciate @ByteHamsterā€™s observation that monitoring user behaviors would be counterproductive.

This voting idea makes sense to me.

7

Would you mind creating a separate thread under the ā€˜Project managementā€™ category? Then that can be discussed in more detail there.

Given that we already have a major discussion on the refresh button here, Iā€™ll set this one to resolved and recommend everyone to continue any discussions there (to keep everything in one place): Changed refresh

8

Itā€™s needed by people who have more than one screenā€™s-worth of podcasts because pulling down scrolls the list rather than refreshing it.

9

There may be confusion about scrolling down vs. dragging the screen down. If you keep pulling it down (after reaching the top of the list) it will refresh.

10

True. Iā€™ve not seen any posts where that confusion has been apparent but for clarity, dragging your finger down the screen scrolls the list until or unless unless the list is fully scrolled. In that condition, performing that same action causes a refresh. Two functions for the same action. The function actioned by the software depends on the conditions at the time of the finger drag. If the list becomes fully scrolled during a drag, the second function(refresh) is automatically actioned.

Does that help?

1 Like
11

Yes it does help, because I always play from the top of the queue, I didnā€™t noticed the problem that pull to refresh only works when I pull go the top of the queue.

I guess if we pull to refresh from the header section where the word ā€˜Queueā€™ + xyz Episodes Time left, then that can be be solved? The UX would be weird?

12

Thatā€™s a good point. If I switch to play from the top of the queue instead of the bottom that would mean a simply pull down would refresh because the active playing podcast would be the focus and there would be no need to scroll. Would the auto-play-next still work in that condition? I would need a set of very short test podcasts to test it without having to wait til my existing ones played and finished.

13

Yes if you play from the top of the queue it which continue autoplay to the next episode.

14

Just tested. It doesnā€™t really help because I want date order with later podcasts played after earlier ones. Because they play from those higher up the display to those lower down, that means I need it to be sorted old at top, new at bottom. Because I play news/topical ones as a higher priority, I have older ones that I have on the queue and go to when Iā€™ve finished with the news/topical ones. That means a queue of more than one screen=size will form and Iā€™m back to not having refresh on a simple pull-down. Best solution is either have the old and well-loved behaviour back or have the button choice configurable. (I believe)