Add episodes without subscribing

[ByteHamster]

Description

Adding episodes to the queue without subscribing is a long running feature request. Doing this does not really make sense on a distributed podcast app. However, to make these people happy, subscribe to the feed internally anyway and just tell them that it is not subscribed.

Closes #4710

ToDo:

• Do the "non-subscribed" feeds end up in opml/html exports?
• Unsubscribe automatically after a while when no episode is queued or downloaded
• Do the feeds end up on the sync server?
• sync after subscribing
• move subscribe code to dbwriter
• searching on the podcast screen of a non subscribed one should work
• use button "preview", not " view episodes"
• show episodes list preview in online feed popup, not in normal app page. Then we can keep the buttons as they are and only display subscribe
• I think the current implementation might lead new users into never discovering the per podcast settings because there is no reason for them to ever subscribe. The app works just fine wirhout it. (Until at some point the playback states disappear, at which point they will blame AntennaPod) Show the settings button even for non subscribed podcasts but then refuse to open the settings ("Subscribe to change settings"). Maybe that is more of a nudge than simply not displaying the settings button
• With a very fast network connection, the non subscribed podcasts open almost immediately. That might make users think that the additional popup (old onlinefeedview) is just the way navigation works in AntennaPod. If a podcast is already in the database but not subscribe, delay loading the page such that they see that everything goes faster once subscribed. Something like 3 seconds could work (minus the time it takes to actually load)

Earlier ideas, maybe not for now

• Maybe display some text like "the playback state of non-subscribed podcasts is removed after a while. Press "subscribe" to fully add the podcast to AntennaPod".

Checklist

• I have read the contribution guidelines: https://github.com/AntennaPod/AntennaPod/blob/develop/CONTRIBUTING.md#submit-a-pull-request
• I have performed a self-review of my code
• I have run the automated code checks using ./gradlew checkstyle spotbugsPlayDebug spotbugsDebug :app:lintPlayDebug
• My code follows the style guidelines of the AntennaPod project: https://github.com/AntennaPod/AntennaPod/wiki/Code-style
• I have mentioned the corresponding issue and the relevant keyword (e.g., "Closes: #xy") in the description (see https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue)
• If it is a core feature, I have added automated tests

[keunes]

Do the "non-subscribed" feeds end up in opml/html exports?

I would say they shouldn't. As the user is not actively subscribed to them.

Do the feeds end up on the sync server?

I would say they should, as we should synchronise the playback status of all episodes.

[ByteHamster]

Do the feeds end up on the sync server?

I would say they should, as we should synchronise the playback status of all episodes.

This would mean we would send a "subscribe" event to the server, so the feeds would start showing up as normal subscriptions on all other devices. That can't be the expected behavior. To be honest, the checklist was mainly for myself to check that these things don't happen

[antennapod-bot]

This pull request has been mentioned on AntennaPod Forum. There might be relevant details there:

https://forum.antennapod.org/t/download-single-episode-without-subscribing/3825/34

[Matth7878]

I would say it's not a good idea to degrade performance just to nudge people. It would be perceived as AntennaPod not being efficient. I think not having settings should be enough. What does it matters if people don't really subscribe. They are free to do what they want and AntennaPod shouldn't annoy them just because they are supposed to subscribe... 🫤
And doesn't adding code that it's not really needed against "keep code simple for maintenance" philosophy.

[Matth7878]

Thinking a bit more if you really want to nudge AntennaPod should be transparent about it and explain it. Nagging user with a dialog asking to subscribe when user is about for instance to add his 3rd episodes would be better.

[ByteHamster]

Delay removed

[keunes]

Hello,
As discussed in the meeting:

• I would not display a settings button which doesn't do anything. (We could think of a future improvement here, see below.)
• When opening the episodes preview, you see a flash of the usual buttons, before the Subscribe button is displayed.
• When tapping on a podcast in the Subscribe screen, I would like to keep displaying the episode list (as currently happens). Then of course the new system, episode preview list.
  • Having the description page & 'Preview episodes' button as a way to nag users to subscribe is not user friendly at all. (As we nag them while they're just exploring if the podcast might be something for them, without taking any 'dangerous' action.)
  • As discussed it would be great to drop the 'description preview' and display the 'episode preview' directly. Some things to consider:
    • We would have to move some info to the 'episode preview' screen, if the podcast is not-subscribed. It should be displayed between the top container and episode list - how is tbc (either in top container or as part of the episode list container - harder to implement because episode list container cannot currently display anything apart from episodes). To display:
      • First 3 lines of the description, with an option to view view the full description. (Thought after the meeting: Display podcast detail fragment or dedicated fragment for podcast description? Capping the description on the podcast info screen and displaying the full description in a dedicated fragment/dialog could be nice, aligning the two.)
      • A warning which in the current build is displayed on description preview. Style to be changed to that of the filter warning.
    • "Include in auto-download" checkbox. We should get rid of that anyway. @ByteHamster: though maybe not before we have the alternative. Me: I'd be fine with a gap, given that it saves implementing a change that's only temporary of nature (i.e. cut work that'll be thrown away) - users can change it easily if they wish.
    • Alternative feed URLs: we currently have a dropdown (e.g. OPUS vs MP3). This choice would have to be made before adding to the database. Thought after the meeting: drop the choice now in the flow and simply display the feed URL that's being opened. Future improvement could be to implement a 'feed switcher' (building on 'edit feed URL' functionality).
    • What if feed URL doesn't work? Checking & error message currently part of description preview, but could be moved to own dedicated step (before episode preview); show progress indicator until done.
  • Currently when opening the episode preview list, I see a progress indicator starting twice. This doesn't happen on normal podcast view which displays episode. Double because of refresh being triggered when tapping the 'Preview episodes' button and the subsequent reload. Implementing episode display would avoid this by:
    • Relying on usual refresh mechanism on podcast fragment.
    • Kick in feed refresh each time podcast view is opened and podcast is not-subscribed, if podcast has 'automatic downloads' disabled, or even just always (tbd - each have their up- & downsides).

Potential future enhancements:

• The overflow menu in the episode list preview has some unexpected padding. Minor issue, can be corrected later.
• Limit database size:
  • Nearer future: Introduce two-level deletion approach:
    • Long keep: Deleted from database after 30, if noting favourited, in queue or downloaded (as currently implemented). Ideally add 'played' (has playback status or playback completed) as 'meaningful interaction' that's considered.
    • Short keep: Delete from db after 1 day if no meaningful interaction (as listed above) has been done at all.
  • Farther future: add to db only upon meaningful interaction (would require a big update to how data is fetched & displayed in different locations across the app).
• Display the settings icon only on the full-screen version of the podcast screen (i.e. when returning to the podcast after a meaningful interaction/when opened not via 'Add podcast' screen).
• Nagging upon meaningful interaction
  • Add to queue
  • Download
  • Stream if playback position is null AND is-in-queue is no (to not nag twice on the same episode)
  • We don't want to nag on each play action; if the user added to queue and starts playback we should nag only once.

[keunes]

It crashed while tapping on a podcast in the 'Discover' block on the 'Add subscription' screen:

Environment

Android version: 13
OS version: 5.4.219-qgki-g95eb98a8c435
AntennaPod version: 3.3.2
Model: FP5
Device: FP5
Product: FP5

Crash info

Time: 02-05-2024 23:26:57
AntennaPod version: 3.3.2

StackTrace

org.greenrobot.eventbus.EventBusException: Subscriber class de.danoeh.antennapod.ui.screen.onlinefeedview.OnlineFeedViewActivity and its super classes have no public methods with the @Subscribe annotation
	at org.greenrobot.eventbus.SubscriberMethodFinder.findSubscriberMethods(SubscriberMethodFinder.java:67)
	at org.greenrobot.eventbus.EventBus.register(EventBus.java:150)
	at de.danoeh.antennapod.ui.screen.onlinefeedview.OnlineFeedViewActivity.onStart(OnlineFeedViewActivity.java:133)
	at android.app.Instrumentation.callActivityOnStart(Instrumentation.java:1544)
	at android.app.Activity.performStart(Activity.java:8330)
	at android.app.ActivityThread.handleStartActivity(ActivityThread.java:3671)
	at android.app.servertransaction.TransactionExecutor.performLifecycleSequence(TransactionExecutor.java:221)
	at android.app.servertransaction.TransactionExecutor.cycleToPath(TransactionExecutor.java:201)
	at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:173)
	at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:97)
	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2308)
	at android.os.Handler.dispatchMessage(Handler.java:106)
	at android.os.Looper.loopOnce(Looper.java:201)
	at android.os.Looper.loop(Looper.java:288)
	at android.app.ActivityThread.main(ActivityThread.java:7918)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:942)

[keunes]

Much smoother than before – very nice! Few further notes:

• The overflow menu dots turn black only when view hits the description, and thus become invisible for a short moment. Also it feels like the top app bar gets a background too late. If it'd get the background as soon as the podcast cover ends (and the it's change colour at the same time), that'd be nice. (I noticed that the main fragment suffers the same issue. And I remember we discussed before, but shouldn't we expand the episode cover background to be also behind the notification bar?)
• Nice to have: display the (beginning of) the podcast title in the top app bar when it is shown present.
• The margin/padding between Episode heading and list is a bit too big compared to that of the description heading & text.
• It would be nice to have a cross in the top-start of the dialog, so it's clear & easy how to close.
• Would there be a way to make the dialog a bit taller? Or is this a standard format that we'd keep?
• When you open the preview, tap on the description, then go back, the header background is much lighter and the description block & subscribe button are not tappable anymore.
• In the Info screen preview:
  • there still is the 'Statistics' heading (without content under it)
  • I think we can hide the 'Support' section if not-subscribed.
  • I.e.:
    • Stats, if subscribed
    • Support, if subscribed
    • Description
    • URL
  • I think it'd be nice if we display the full description, on top, without heading. Then the URL can go below (it is actually handy to have access to this, e.g. in case there's two times the same podcast in your search results).
  • As a future improvement, maybe the statistics should be moved to the top, as that's probably more relevant when you're already subscribed.
  • Can also be for later, but currently the info screen also has a dark bar at the bottom of the header, which, however, serves no purpose (there's no buttons/icons there). I'd remove it.
• Long-press on episode: I guess we could remove 'Add to favourites', given that this is possible already while listening (player screen) and when viewing episode details (episode fragment).
• When downloading/adding to queue an episode, then
  • opening those episode details, the details open in full screen. Minor thing, but if we want to be consistent in our signals, that should probably also open in the dialog (?) (When opening episode details from the preview, you also see them in the dialog)
  • in the episode details, 'Open podcast' is missing.

[keunes]

Ah, and the point you mentioned already: the notice/warning isn't super visible yet.

I would say that

1. To make it more visible, it needs a background colour
2. It would be nice if we'd align the design across all warnings and maybe notifications.

In terms of design I would say: rectangle with rounded corners; margin equal to the size of the header radius (i.e. where corner radius ends, warning card starts); light blue background with brand dark blue text; probably an i-in-circle icon start-aligned.

[ByteHamster]

The overflow menu dots turn black only when view hits the description, and thus become invisible for a short moment. Also it feels like the top app bar gets a background too late. If it'd get the background as soon as the podcast cover ends (and the it's change colour at the same time)

That's the problem I mentioned in the meeting: We display it as part of the header, not as part of the list. The header is not made for such long things. Displaying it as part of the list would need significant changes to the episodes lists.

display the (beginning of) the podcast title in the top app bar when it is shown present.

That's independent from adding without subscribing, it also applies to subscribed podcasts

Would there be a way to make the dialog a bit taller? Or is this a standard format that we'd keep?

The idea was to make it clear that it is a popup. When we make it larger, it no longer looks floating but basically like a full-screen window.

remove 'Add to favourites', given that this is possible already while listening (player screen)

I wonder if we should remove it completely for non-subscribed ones because marking them as favorites generates quite some complexity in the database with the filtering screens (that usually filter out non-subscribed episodes)

opening those episode details, the details open in full screen. Minor thing, but if we want to be consistent in our signals, that should probably also open in the dialog

I don't think that works because you could also click the episode before and then swipe to the non-subscribed one. I don't want to show a popup there in the middle of swiping.

It would be nice if we'd align the design across all warnings and maybe notifications.

What notifications do you mean? What warnings? I don't think we should make the "filter" warning taller than it is

Data like playback state of non-subscribed podcasts is deleted after a while. Subscribe to keep it.

I'm not 100% sure about the wording of the warning. Any ideas on how to make it better?

[keunes]

As discussed at the Needs:Decision meeting today:

The overflow menu dots turn black only when view hits the description, and thus become invisible for a short moment. Also it feels like the top app bar gets a background too late. If it'd get the background as soon as the podcast cover ends (and the it's change colour at the same time)

That's the problem I mentioned in the meeting: We display it as part of the header, not as part of the list. The header is not made for such long things. Displaying it as part of the list would need significant changes to the episodes lists.

This requires moving the warning to the list part of the screen, which requires architectural changes, which will already be required for #6191 so we don't need to track it separately.

display the (beginning of) the podcast title in the top app bar when it is shown present.

That's independent from adding without subscribing, it also applies to subscribed podcasts

I will create an issue so we can discuss further later.

remove 'Add to favourites', given that this is possible already while listening (player screen)

I wonder if we should remove it completely for non-subscribed ones because marking them as favorites generates quite some complexity in the database with the filtering screens (that usually filter out non-subscribed episodes)

Episodes of not-subscribed podcasts are hardcoded to be filtered out everywhere (except the podcast view & queue). Favouriting can be used also as temporary bookmark; it's not strictly about favouriting. The hardcoded filter logic could be changed, but it might make slower the queries just to support additional stuff for not-subscribed stuff which is not desired. Better solution might be: as soon as sth like favourite appears in filter, then remove the not-subscribed filter.

Data like playback state of non-subscribed podcasts is deleted after a while. Subscribe to keep it.

I'm not 100% sure about the wording of the warning. Any ideas on how to make it better?

Playback state and history of non-subscribed podcasts is deleted after a while. Subscribe to keep it.
Change filtering logic on playback history screen so that also episodes of not-subscribed podcasts are displayed.

I think it'd be nice if we display the full description, on top, without heading. Then the URL can go below (it is actually handy to have access to this, e.g. in case there's two times the same podcast in your search results)

Changes already applied through another PR, to add: make 'Description' heading conditional as well on subscribed state.

[ByteHamster]

Will be released in AntennaPod 3.5.x